GutPlans was a personalized nutrition product designed to turn gut-test food recommendations into something people could actually use: recipes tailored to what their bodies could tolerate.
What started as an ambitious automated meal-planning ecosystem became a much more focused product — because we listened to behaviour instead of defending the original idea.
The early paid pilot achieved approximately 18% signup-to-purchase conversion without paid marketing, giving us an early signal that people were willing to pay for the problem we were solving.
Original landing-page design, including its recipe-book mockup. The proposition became concrete, practical and easy to explain.
The food-entry interface groups recommendations into recognizable categories.
An archived recipe-detail screen makes the personalized output tangible.
Gut-test recommendations went in. A personalized, usable recipe experience came out.
Our research focused on health-conscious people who were already trying to eat well. They had advice, test results and a theoretical sense of what they should eat. The hard part was translating that information into a decision they could make tonight.
The gap wasn’t simply knowledge. It was the gap between knowing and doing.
A persona synthesis from the original research.
Detail from the original journey map. Open the image to see the complete journey.
Foodeasy began as a connected ecosystem for discovering recipes, planning meals, managing preferences, shopping, pantry tracking, quantities, nutrition and ongoing personalization. The architecture became sophisticated. So did the UX.
We had designed an entire ecosystem before proving which part people actually wanted.
The original architecture connected user needs, features, workflows and technical requirements.
The database model shows the hidden weight behind the interface.
The early product architecture connected recipes, meals, preferences, shopping, ingredients, stores and personalization.
Our biggest constraint wasn’t creativity. It was resources. Every workflow would eventually need to be built, tested, maintained and explained. Before committing to full development, we changed the question.
Instead of waiting for the complete platform, we put enough of the proposed value in front of potential customers to learn whether interest could turn into actual purchase behaviour.
Early hypothesis and business-model notes. Targets on this working board are plans, not measured outcomes.
Paper screens let us explore the experience before committing to implementation.
An archived trial-planning artifact, rather than a polished product screen.
An early signup experiment. This screen documents the invitation, not completed purchases.
We were testing willingness to act — not whether people liked our screens.
Research and purchase behaviour pointed toward a more specific value proposition. People did not necessarily want an enormous meal-management system. They wanted help making personal health information useful — without taking on another complicated system to manage.
More features → clearer value
The earlier platform asked users to plan, customize and maintain a recurring routine.
Original mobile explorations show the interconnected experience we initially pursued.
The later landing-page explainer reduced the proposition to a short path to something useful.
Less ongoing management.
More immediate, recognizable value.
The product depended on one unavoidable moment: users had to tell us what their gut-test provider recommended. Those recommendations could contain many foods across categories and grades. Structured data for the system could easily become a very long form for the customer.
We turned input into recognition. Foods were organized into recognizable categories and clear recommendation states. Users could progressively enter or update information while understanding the structure behind the final personalized output.
Don’t make users experience the complexity required to personalize their experience.
Users could paste and review foods within recommendation categories.
Explanatory diagram summarizing the experience, not a screenshot of the underlying algorithm.
The recipe screen carries recommendation grades into a familiar cooking experience.
The goal wasn’t the world’s most elegant technical stack. It was getting closer to users, shortening feedback loops and reducing unnecessary handoff. Low-code and no-code helped us iterate as the proposition changed.
Original implementation review with interface fixes and priorities.
Original design-file capture showing account creation and onboarding.
An actual workflow-editor capture from the later recipe-book product.
The best implementation approach for an uncertain product is often the one that makes changing your mind cheapest.
We had invested real thought in automated meal planning, shopping workflows, personalization logic and an entire food ecosystem. There was good work in those ideas, which made them harder to abandon.
But a startup doesn’t get points for how much thoughtful UX it produces. It survives by finding something people value enough to use — and eventually pay for.
The pivot taught me that good product design sometimes means protecting an idea. And sometimes it means being willing to say:
“We don’t need this anymore.”
Turn your gut-test recommendations into food you can actually eat.
Recipe-book mockup from the original landing page. Open to see the complete source design.
The recipe-book product asks for the information it needs to personalize the output.
Archived recipe UI connects food recommendation grades to ingredients and instructions.
The final customer-facing product presented a digital recipe book built around each user’s gut-test food recommendations. Instead of another health dashboard to manage, customers received something practical.
Meal planning, discovery, grocery shopping, pantry management, nutrition and personalization became one connected platform.
People could express enthusiasm without changing their behaviour. Purchase behaviour gave us a stronger signal.
Every feature increased design, development, testing, maintenance and onboarding cost.
As the product changed, we needed an implementation approach that could change with it.
Research helped us understand the problem. Prototypes helped us understand the experience. But actual behaviour helped us understand the business. Sometimes the strongest evidence is not what someone says they like. It is what they choose to buy.
“I like this.”
“I bought this.”
The broader exploration wasn’t wasted. It helped us understand the ecosystem and where opportunity existed. But a startup benefits enormously from separating two things: