Once A Month Meals (OAMM) offers users everything they need to make freezer cooking easy with customized resources and a supportive community. OAMM came to Sparkbox several years ago with a belief that families should eat together. The OAMM team had years of experience manually perfecting an efficient “OAMM Way” to plan, cook, and freeze thirty meals in one day and had developed a process to create resources to help others do the same. The team wanted to be liberated from their painfully time-intensive processes and use their time for what mattered most: helping other people find time for what matters to them. Over the last three years of working together, Sparkbox has intentionally built a robust, customizable menu system to let users around the world make their own unique meal plans that capitalize on OAMM’s expertise in making the process fast, easy, and efficient. The OAMM team has seen enough value from its investments that it was able to hire six fulltime employees (including one fulltime developer with another on the way) and turned a cooking blog into a self-sustaining software business.
Over the last three years of working together, Sparkbox has intentionally built a robust, customizable menu system to let users around the world make their own unique meal plans.
Setting the Course
While talking with the OAMM team members about their process, we quickly realized that our original plan (to harness the team’s knowledge to produce efficient, fast meal plans and turn that into a powerful engine) was going to be a huge undertaking. We needed to create a plan of attack on two fronts—the first was to safeguard our grand plans by submitting a patent and the second was to come up with a sustainable way to build the system over time. To help set OAMM up well, we created wireframes for the grand vision and helped the team write and submit a patent based on its plan for the big picture freezer cooking engine.
Building the Engine
Before we could build anything else, we had to first replicate the knowledge OAMM had about designing freezer cooking days and turn it into code so the computer could consistently do it for them. One of the first efforts that made sense to tackle was understanding what OAMM already knew how to do—take a regular recipe and adapt it to work for bulk freezer cooking. This was a long, deliberate, iterative process that required a lot of hands-on testing—both on the computer and in the kitchen.
As part of the initial effort, we also formed a new brand, transitioning from Once a Month Mom to Once a Month Meals to better capture the true audience and potential reach the service offered. We then applied the new branding to the existing WordPress site (changing the header and some colors). Then we set to the big effort of creating the system a bit at a time.
Menu and Cooking Support Documents
The first feature we were able to introduce was a widget that was able to replace the time-consuming task of creating multiple menu and cooking support documents. Six whole documents that used to be manually created by people (shopping lists, prep instructions, cooking-day instructions, recipe cards, labels, and thaw sheets) were able to now be generated by the computer. This took a tremendous amount of trial and error.
The heart of the system is an application that can take a given set of recipes and design an efficient freezer-cooking day. By working through seemingly simple, but truly complex tasks (like figuring out how to scale ingredients that can’t be cut in half, like an egg) we were eventually able to get to a point where our documents looked like the documents the OAMM team manually produced. At that point, we had to find test cooks to actually prove our documents were as good as the people-produced ones. Test cooks, as well as continued knowledge sharing and discussions with OAMM, were key to making a system that worked. We’d often find that after getting everything working in one case, we’d put in all new recipes and realize there was something else unaccounted for. This deliberate process allowed us to keep decisions simple and allow the complexity to show up during testing and then solve them.
The heart of the system is an application that can take a given set of recipes and design an efficient freezer-cooking day.
What we realized quickly was that the human instructions and system instructions would be different. But what we found was that our system was able to generate more consistent instructions that were better, because we removed the human error component. Using test cooks became a way to prove that we had all the nuances and decisions included in the system from the OAMM team. We were able to make sure everything was done in the right order and teach the system to make good decisions for us through code and metadata.
One of the things to consider when cooking thirty meals in one day is how to optimize everything. You can’t allow yourself to waste time on silly mistakes, like waiting 15 minutes for your oven to cool down from 450 degrees to 375. Did you notice in the image above how the first item of “oven cook” is for 375 degrees, and the next two are both 450? Little touches like that take a lot of planning and iterating, but they were critical to making things work well for users, which was a must for OAMM.
In order to let the system understand these nuances, we needed OAMM to move from freeform recipes and menus into highly thought-out, structured data that allowed us to:
Calculate the ingredient amounts needed based on serving amounts. This can be especially tricky when you need to convert the number of cups of red pepper needed in a recipe into whole peppers purchased at the store.
Create custom shopping lists based on serving amounts and recipes.
Know how many freezer containers you’ll need for your recipes.
Provide custom instructions—not only for the day you cook, but also all your instructions to prep and serve the meal when you’re ready to enjoy.
After launching the freezer-cooking application, users saw a large improvement in resource consistency, and the OAMM team saw a huge time savings that allowed it to invest its time in better areas and look to the future.
After launching the freezer-cooking application, users saw a large improvement in resource consistency.
Adding user-management capabilities to the system allowed OAMM to invest in the future. This feature meant the team had complete control over billing and user information, and it opened the door to expanding into different social aspects of the community it had been fostering.
Freezer-Cooking Application with Customization
After learning how to create efficient freezer-cooking days, we were able to go a step further and design an application that allowed users to customize menus to their preference and get all their resources tailored to their choices. This new system made use of all the work we had previously done to automate creating cooking-day menus and resources and now allowed all users to create unique cooking instructions on the fly—no matter what recipes they choose or how many people they’re cooking for.
A Hunk at a Time
Working with a startup, we recognized it was our job to help counsel OAMM on how to responsibly evolve the product over time. We needed to help them prove success and see financial gain from improvements as soon as possible, while also making good progress toward the grander vision. This meant taking the larger picture and breaking it down into actionable steps (menu and support documents > an engine that could design freezer-cooking days with a web application that allowed OAMM to have a great, consistent user experience across devices without resorting to specific device apps > and then the ability to customize recipes for freezer-cooking days). We also relied on sturdy existing solutions (such as Solr Search), where possible, to provide minimum viable products that could be extended on. And we added features when the benefits were right.
Redesign and API
After seeing big success from its investments in the freezer-cooking day engine, OAMM’s recent redesign allowed OAMM to turn its robust backend system for managing menus and recipes into an API that now drives the blog while giving everything a bit of a facelift. This project was the last piece in making the grand vision a reality. One of the most exciting realities of doing the work was that it included us working with OAMM’s first fulltime developer on staff (a hire made possible through the financial success of previous work that proved the business’ viability).
The redesign included updates to the brand to further evolve it into the smart and approachable product it had become. The primary goals of the redesign were to:
Make it easy to learn about membership and become a member.
Make the different applications that supported the community (a WordPress site, an engine for building and customizing menus, and an account management area) feel like they all belonged together seamlessly.
We started design by creating element collages of a couple possible visual directions. This allowed us to show and get feedback on visual design quickly. We selected a few different types of content that would be housed on the site such as a recipe “card” and hero photo as well as text, buttons, headlines, and a few UI elements. These were presented, and after some discussion, a visual direction was chosen.
The MenuBuilder system and frontend were perfectly fine and required nothing more than a mere facelift once the new header and footer were in place.
This most recent redesign effort, launched in early March, was showing improvements in the very first month for OAMM with a whopping 66% improved bounce rate. Coupled with a 41% increase in the number of pages viewed per session and a 10% decrease in session duration means users were excited about the content they found when they got to the site and were able to consume more content in less time. The redesign was able to bring the main site up to snuff with the applications and show off OAMM for the powerful, useful system that it is.
66% improved bounce rate
41% increase in the number of pages viewed per session
The Next Phase
Since we started working with them, OAMM has hired a full-time developer, a part-time contract developer, six additional administrative contractors, and has plans to hire another full-time backend developer in the next few months. This is part of a gradual, intentional transition of the project to an internal team. The success is bittersweet, but it is the fruition of our shared plan to help make OAMM self sustaining. So, as sad as it is, we’ll be happy to see them go and continue to grow their success.