Audit the current systems

When we first started working with Prefare, there were two separate customer portals running simultaneously, each with their own front-end experiences, databases, billing systems, and reporting. One system was the original version of Prefare that we called 1.0. This was a custom Angular app running on node server in AWS.

The other system was a newer implementation, which we dubbed 2.0, that was mostly running on Shopify but also had a custom Heroku server to help manage billing and subscriptions. Additionally, there was a Webflow site that served as the marketing homepage.

In this old system, lots of manual work was done each week in Excel spreadsheets to combine the customer orders from each system so that they knew how much food to make. When a new recipe or menu was created, updates needed to happen in multiple systems since 1.0 and 2.0 did not talk to each other. Not only did this create a lot of additional work for the Prefare staff, but it was also very error prone.

Create a technology roadmap

The first step for the Fresh team was to understand the pros and cons of each of the two systems, define the product/technology requirements of the future state, and come up with a plan for how to move forward.

The original 1.0 system was processing more than 90% of all orders but was and old, bespoke system with no automated testing and lots of code duplicated across the front-end and backend. This meant making changes was very risky. It also did not have a standalone API tier, which would make adding a mobile app in the future more difficult.

The 2.0 system was built on Shopify, but we quickly found that most of the benefits of using Shopify were not being leveraged, such as billing, user management, and product/inventory management - all of these were happening in a separate bespoke system. As as result, there was also no unified API tier in 2.0.

So we proposed a new architecture: a single JSON-based RESTful API that would power all client applications, starting with a React application. This setup would allow additional clients, such as iOS or Android apps, to be build later, consuming the same API. This new system is known as 3.0.

3.0 Rollout & Data Migration

We spent several months building out the new platform including CI/CD pipelines, automated testing, staging and production environments, and more.

A critical consideration of the new system design was data migration. We reached out to a small number of existing users to be part of a "beta" program, giving them some free meals and access to the new portal. After a few billing cycles and bug fixes we were feeling confident enough to move everyone over to the new system.

Since most of the existing customers were running on the custom 1.0 application, we were able to write database scripts to export all of the data and load it into the new 3.0 schema. We were able to do this in a way in which a user would not have to set up a new password when they were switched over to the new platform! Getting the relatively small number of users over from Shopify was another story. We ended up creating a communication plan to help walk the users through the upcoming switch, and through some great customer support by the Prefare team, we were able to get everyone moved over manually.

In the end, the new system worked great without any issues! Customers are happy, Prefare continues to grow, and if you want to be a hero in the kitchen, check out PrefareMeals.com