How I designed and built LazyMeals with AI

LazyMeals is a meal planning app I designed and have been building with AI-assisted development. It plans the week around everyone in the household, then turns the plan into a grocery list and step-by-step recipes. At the time of writing, in late October 2026, it hasn’t launched yet. It’s expected to launch on Android and iOS on 1 November 2026, and lazymeals.app has the latest.

I’m a UX and product designer, and LazyMeals is where I’ve tested how far that role can go when AI does much of the implementation. This case study covers the product decisions, how I prepare, direct and test the build, and the most useful thing I’ve learned along the way: AI doesn’t always choose the smartest path to the goal, so it has to be guided.

The problem

Every week the same question comes back in our household: what are we going to eat? It isn’t a hard question, but it returns every week and brings others with it. What does everyone feel like? What do we need to buy? Who is cooking what, and when?

We had looked for an app to help. There are plenty of meal planning apps, and several are good. We just didn’t find one that planned around the people we actually cook for, gave us a plan we could adjust instead of building from scratch, and turned that plan straight into a grocery list. So I decided to build one.

LazyMeals isn’t a new category of app. People have planned meals on paper, in spreadsheets and in apps for a long time. It started as an answer to an everyday problem in our own household, not a gap I spotted in the market.

Designing the product

This part is my day job. I’ve worked in UX since 2014, and I approached LazyMeals the way I would a client product: start with the people using it and the job they’re trying to get done, then decide what the product should and shouldn’t do. I designed the app’s interface in Figma.

A few decisions shaped it more than the rest:

• A conversation instead of a form. Onboarding is a short chat about who you cook for and what you like. Forms and filters ask you to translate your life into someone else’s categories. A chat keeps getting started light.
• Households, not single users. Most people don’t cook only for themselves. You add the people you cook for, including children without their own account, and each person can have their own preferences. The plan is built around all of them.
• One flow from plan to plate. You get a draft plan that you can adjust in your own words, or swap a recipe you don’t fancy. The plan then becomes a grocery list, viewable by ingredient or by recipe, and each recipe can be cooked step by step with timers where a step needs one.
• Being clear about what it isn’t. LazyMeals isn’t a calorie tracker and doesn’t log what you eat. Keeping it focused on planning was a deliberate choice.

There’s more on the UX side in the LazyMeals case study on my UX page.

Preparing before building

I didn’t start by asking AI to build an app. Most of the work before any code was preparation.

Throughout that phase I used ChatGPT as a thinking partner: discussing ideas, brainstorming, refining approaches and developing prompts. I also used it to draft the first versions of the specifications Claude Code would later work from. There’s one for each part of the product: account and onboarding, meal planning, recipes, cooking, the household, groceries, preferences, notifications, subscriptions, search, and how the app’s own AI should behave. Alongside those are documents for the data model, the technical architecture and the testing strategy.

Drafting them was the quick part. I reviewed every document myself, and I used ChatGPT to cross-check the documents against each other several times, looking for places where one specification contradicted or missed something in another. The aim was a set of specifications that agreed with each other before implementation started. The decisions in them are mine.

This is the same kind of documentation I’d hand to a development team, and it’s what makes AI-assisted development workable. An AI coding tool fills gaps with assumptions. The fewer gaps there are, the fewer assumptions it makes.

One principle from those documents matters for the rest of this story: the app’s own AI is there for what genuinely needs it, such as understanding what people write, personalising and generating, while ordinary, predictable operations are handled by normal application logic.

Directing the build

The app is built with React Native, Expo and TypeScript, with Supabase as the backend and Stripe for subscriptions.

The implementation is primarily AI-assisted, using Claude Code, and my role is to direct it. The specifications and the final Figma designs are the source of truth. Claude Code works in steps: understand the relevant rules, plan the change, implement it and report back what changed. When something needs a product decision the documents don’t cover, it should stop and ask me rather than choose on its own.

In practice I move between ChatGPT and Claude Code as needed: refining instructions, working through questions that come up, and updating the specifications when a decision changes. It’s a structured loop, not a single request.

Testing it myself

AI can speed up implementation a lot. It doesn’t make the result right.

I test the app myself throughout development, at every step, and I only approve an implementation once I’ve tested it and seen that it works as intended. I’ve spent many hours doing that. It’s the part of the process I’m least willing to hand over, because it’s where I find out whether what was built is what the person using it actually needs.

So there are three kinds of work, and they’re worth keeping apart:

• Designing the product: what LazyMeals does, what it leaves out, how it should feel, and the interface in Figma.
• Directing the implementation: preparing and reviewing the specifications, deciding what gets built next, giving the AI the right context, and making the product calls it brings back.
• Checking the result: testing the actual app, finding problems and deciding whether the result is good enough to keep.

AI helps with the second. All three remain my responsibility.

The lesson: AI needs to be guided

AI doesn’t always choose the smartest path toward the goal.

In LazyMeals, the first approach generated recipes and made people wait at each step. It produced a plan, but it treated every step as a reason to generate something new, and the person had to wait each time.

A smarter approach was possible. The app already knows a lot about a household’s preferences. It can use that to predict the likely choices, and only ask the person, or generate something new, when it can’t confidently predict what they want.

At the time of writing, that approach exists in LazyMeals’ development code, but only there. It isn’t part of the main version of the app or any released version, so it isn’t available to users. Within that development code, the app has started moving in that direction: when planning a week, it first uses recipes from its own library that it can confidently match to the household, and only generates the ones it can’t. The planning conversation asks follow-up questions only when the plan needs the answer.

The first approach wasn’t broken, and the problem wasn’t really a coding problem. Building with AI isn’t simply accepting its first implementation. You still need to understand what the user is trying to achieve, question the approach you’re given, and guide the system toward a better experience. That’s product thinking, and it’s the part AI doesn’t do for you.

What else AI didn’t do

AI didn’t decide what LazyMeals should be. Working out what the app should do, what it shouldn’t do and how it should feel to use was still the actual work, and it’s the same work I do on client projects.

It also didn’t remove the parts of a product that aren’t code. A product people can rely on needs a privacy policy and terms that say plainly what happens with their data, prices that are easy to understand, and the work of meeting app store requirements. Some things I’d like LazyMeals to do are deliberately left for later, so that what’s in the app works properly.

The website is a separate project

The app is only part of the product. LazyMeals also needed a website people can read in their own language, so lazymeals.app is in English, Swedish and Danish. It’s a separate codebase from the app: a static site built with Astro and hosted on Cloudflare. I built it with AI-assisted development as well. Before launch, its early-access list used double opt-in, so people confirmed their email before they were added.

Launch

At the time of writing, LazyMeals hasn’t launched yet. It’s expected to launch on Android and iOS on 1 November 2026. You’ll find the latest, and where to get it, at lazymeals.app.

If you’re thinking of building with AI

If you have a product idea and wonder whether AI-assisted development could get it to a first working version, the lesson from LazyMeals is to start with the product thinking, not the tool. Write down what the product should do, decide what matters to the person using it, and then direct and review the build with that in mind.

That’s how I work with founders and product teams too. Read more about building digital products with AI and about UX and digital product design.