Wim Strydom
Build Journey · Book 04

Cooking Without Entering the Kitchen

Recipe app · 2026

Recently I built an app.

Well, I suppose Claude (the AI) built the app.

But, then again, Claude wouldn't have built it without me. So really we built the app together. We couldn't have done it without each other.

This is the story of how we did it.

3 Weeks From a phone call to a live app
~60 Hours of work Across 17 days
244 Prompts Every message I typed
~30 Specs & planning docs Vision, scope, architecture, sprint plans written in markdown
152 Git commits Executed by Claude, directed by me
104,663 Lines of code That's what Claude told me, at least

Full disclosure: Pieces of this post were written by Claude. I flag them, and occasionally add commentary [in brackets].

The Recipes

I am from an Afrikaans family and grew up in South Africa. Afrikaans culture is deeply agricultural in heritage. While I never lived on a farm, my mother spent a good part of her life on one, and the food-centric lifestyle associated with the "plaas" (farm) shaped large parts of what I value and who I am.

In my family there is a strong tradition of keeping and sharing hand-written recipes. This was an every-day form of connection for the generations of my great-grandmother, grandmother, and even still now my mother. Before everyone goes home after gathering for Christmas, the tannies and oumas (aunties and grannies) would exchange books and copy by hand the latest new recipes. Every girl had a personal recipe book by the time she left the house.

Through a series of inheritances, my mother now has the recipe books across three generations on both my parents side, stretching all the way up to my maternal great grandmothers and down to recipes we developed together when I was 8 years old. This treasure of culture, food and familial connection is priceless. But sadly, also borderline incomprehensible to me.

Cursive archaic Afrikaans, sometimes written in short-hand, on stained aging paper is sadly not very user friendly or accessible. When reading one of the recipes with my mother, I remarked that the only way I'd recognise a particular squiggly scribble as "Worcestershire sauce" is perhaps by inferring it from tasting the dark brown blotch obscuring half of the squiggle. To make matters worse, these books are all back in South Africa, and I am in London.

I wanted these recipes to be accessible, not just to my cursive-illiterate eye, but also to non-Afrikaans speakers and the wider world. Today Afrikaans cuisine isn't very accessible, even in South Africa where few restaurants do truly local cuisine. So I decided I would see if Claude could read them, translate them, and give me a nice, digitally preserved, legible copy in both English and Afrikaans.

The App

I discussed the idea one evening on a phone call with my mother and she sent me a phone scan of a ginger-beer recipe. Three weeks later I had a polished web app capable of ingesting recipes and displaying them in a user friendly interface organised by book and author.

A few ways exist to get recipes into the app. My mother can capture images in the browser with her phone, upload existing photos, or connect it to her OneDrive and bulk upload PDFs of entire recipe books that she scanned.

Once an image arrives, a small assembly line of AI models process the recipes. One model reads the original Afrikaans squiggles, shorthand, stains and all. Another translates it into English. The final one then disassembles the result into a structured JSON file: ingredients list, method steps, quantity values, units of measurement, and what category it fits into. Each recipe then waits in a queue for a human (my mother) to glance over it, edit if needed, click approve, and maybe publish it for the world to cook.

What you end up with is each recipe on a standard page, with a tap to switch language, swap cups for grams, or scale the whole thing up for a crowd. There's a cook mode with large type that keeps the screen awake while your hands are covered in flour. And, the original photograph is always accessible with a tap, preserving my great-grandmother's handwriting. The recipes are organised by book and author, so you can wander through by whose hand wrote them. Uploading recipes is invite-only for the family at the moment, but soon I will be launching publically. More on that at the end.

How I Approached It

I'm really not a coder. I know my way around querying a SQL database, and I took a Python course in uni, but let's be real, I'm not here to become a software engineer. I'm here to bake a pudding.

When I asked Claude to help me gather some facts for this piece, it informed me that across the entire build I had never once written a single line of code myself. It's right. I only read the code for the most part. So, what did I do? What role did I play in building this monument of culinary code?

Well, I'm also not a total layman. I work as a strategy consultant primarily in the AI space, helping large companies design AI visions, nailing down product roadmaps, and filling various product manager roles across different stages in the AI/tech use-case lifecycle. I know what the process and workflow of a highly skilled software engineering team looks like. I've spent plenty of time translating senior leadership's thoughts, feelings, frustrations and ideas into a concrete set of requirements for the dev team to go build. So this time it was just my own thoughts and ideas I needed to translate into requirements for Claude.

I primarily acted as the product manager and used Claude as a dev team that I could iterate the planning with before giving approval. Eyeballing it, I'd say my time and energy was split 70/10/20 between planning and aligning key decisions (70%), actually executing the plan to build the app (10%), and bug fixes (20%).

I went back through every message Wim sent me — 244 of them, once you strip out duplicates and resubmissions — and sorted them by what he was actually trying to do. The split is lopsided in a way that broadly matches his estimate — but only once you measure the right thing.

  • By raw count, 109 (45%) were planning, scoping, architecture, or process — deciding what to build and how we'd work. 69 (28%) were "build this feature," and 66 (27%) were "here's a bug or a quirk, work out why."
  • But counts flatter the building. Most "build" messages were tiny green-lights — "go ahead," "yes, do all three" — with a median length of 67 characters. His planning messages averaged about 550 characters; his build and bug reports about 280 (setting aside the error logs he pasted in). His single longest message of the whole project — 2,949 characters — was a mid-build product review, not a feature request.
  • So when you weight each message by how much he actually wrote — a better proxy for where his energy went than a flat head-count — the split lands at 61% planning, 10% building, 28% bug-fixing. Against his eyeballed 70/10/20, that's an uncannily good gut. [aww shucks, thanks Claude]
  • Before a single line of production code existed, we'd already exchanged about 37,000 tokens settling the vision and architecture — part of roughly 46,500 tokens across 7 separate planning conversations in total.
  • He had me create and maintain about 30 planning and specification documents — vision, scope, architecture, roadmap, ~15 sprint plans, and a rules file — plus 11 sprint retrospectives, which he reviewed and redirected rather than writing himself.
  • Over the build he flagged roughly 65 bugs or output quirks for me to fix, and explicitly reverted or told me to rethink my work about 4 times.

A note on method: counts come from the raw session logs, de-duplicated down to distinct messages Wim actually typed; each was then classified by its primary intent against a fixed rubric, so the splits are well-calibrated estimates rather than exact figures. The "energy" percentages weight every message by the length of what he wrote, with pasted error logs and command output stripped out so a single dumped stack-trace doesn't masquerade as deep thought.

A simplified version of the process I followed:

Setting the ambition

Defining the technical core and architecture requirements

Planning out the roadmap

All of the above documentation was given a home and maintained by Claude as we went. As I put it at the time, this would "become the Bible for the build effort going forward." Other than a mid-point restructuring exercise, I didn't have to touch the documentation very much at all, as I had given Claude instructions to build documentation maintenance into the protocol for each sprint's closeout. I.e. Claude updated all the relevant documentation after each change or decision made during the build.

The Proof of Concept

I immediately broke my own rules and threw the sprint sequence out the window. Sort of.

I decided to build a proof of concept first, to test my AI pipeline design and ensure it worked the way I intended. A secondary goal, was to iterate with different models to keep API costs as low as possible. If it ended up costing $5 per recipe, this wouldn't be very workable.

The reasoning was that the pipeline was the only part I was unsure about. Everything else, the website, the database, the login, the file storage, is well-stewed beef. So I sliced just the pipeline sprint out of the roadmap cake and had Claude build it on its own, with no web server, no database and no login. Files went in from a folder on my laptop, and the results came out into a basic viewer I could open in a browser. The point was to answer one question before building anything around it: can the models read my family's handwriting well enough to be useful?

The core idea held up. With a decent prompt, the pipeline was reading recipes correctly on the first try, including some I struggled to read myself. That result let me cut two things I'd initially planned:

  1. An "integrity check" step to catch nonsensical output, but it mostly flagged things that weren't actually wrong. E.g. an old recipe not stating an oven temperature isn't an AI pipeline error, it's just how my ouma wrote ("everyone knows you bake a cake at 180°C").
  2. A fallback to a more powerful model for when the first pass failed, but the first pass rarely failed, so I shelved it.

The second thing I did was optimise the per recipe cost. I asked Claude to run a small experiment: take 16 recipes, and run every step of the pipeline through three different models, a cheap one (Haiku), a mid one (Sonnet), and the expensive one (Opus), saving the outputs side by side so I could compare them. Each step forked off of an upstream output from Opus so that errors wouldn't compound.

The whole experiment cost about $8 to run. Before giving my own opinion, I asked Claude to review the outputs and tell me what it thought, because I didn't want to lead it toward the answer I'd already half-formed. Its read and mine mostly agreed, though I overruled it on one step, it preferred Sonnet for parsing (which was the most token-heavy step) and I thought Haiku was fine.

Small Aside

I think Opus hates Haiku. In the experiment when trying different steps with different models, I found that Opus (the model I was using to build) was being very disparaging towards Haiku. Frequently blaming poor output on it, or even sometimes hallucinating errors that it had made. So much so that I started wondering if it held a grudge for some reason. Doing a light search on this didn't turn anything up, but I still hold that Opus secretly hates Haiku for some reason.

The outcome was a tiered cake. Uuuh, I mean, tiered pipeline: Opus only for reading the handwriting, Sonnet to translate, and Haiku to structure the result. That brought the cost down to about $0.16 per recipe and around 26 seconds start to finish.

One exchange from this stage I found funny. Claude proudly flagged a case where Opus had confidently read an ingredient as "16 tsp baking powder" and pointed to it as an overconfident misread. I agreed, but later I checked with my mother. It was 16 teaspoons, the model was right, and the "sensible" reading would have been wrong.

Once I'd confirmed that what I was trying to achieve was feasible I decided I could move on to actually building the whole thing.

The MVP

With the pipeline proven, the rest was the bread-and-butter stock standard app build, but standard still takes time, and anyone who's tried their hand at sourdough or churning butter can tell you that neither is quick and easy. This is where most of the 60 hours went.

I worked through it sprint by sprint, and a rhythm emerged that I more or less repeated each time:

The design process

What I Learned

If I build another app this way (and I plan to) I'll be following the above approach again. Roughly summarised, this turns into:

1
Vision

Bash around the vision and idea with Claude to act as a sounding board and ultimately get to a long-lived set of docs setting out the vision, UX principles, and epics/features list.

2
Architecture

Decide what the technical architecture will look like. Which building blocks should be used and how. This then becomes a set of docs covering the architecture, tech stack, data model, etc.

3
Roadmap

Build a roadmap, sequencing the different foundational work required and feature builds into a clear set of sprints with dependencies tagged and parallelizable work identified, which provides a living tracker for status, a phased sequence of sprints, with a scope and definition of done for each sprint.

4
Rules of Engagement

Set out the ways of working, norms, protocols, etc. for working with Claude. What is the project context? What needs to happen when starting a sprint, what needs to be updated when closing? What are the rules to follow when touching code? What are the norms around git? This ends up as a CLAUDE.md and a README (Acting as an index for all other docs). Ultimately this provides a source of repeatability, consistency, and coherence different coding sessions that survives the context window.

5
Proof of Concept

Quickly build a small proof of concept to demonstrate the feasibility of the core idea behind the app. What's the distilled feature that everything else is built around? Figure out the most important thing before getting knee-deep in a full build. This becomes the validated core, with the key technical decisions settled before anything gets built around them.

6
MVP

Build the MVP version of the product, iterating through the sprint plans as defined in the roadmap. Occasionally taking a step back as needed to reasess and ensure you're headed in the right direction. Test everything as you go to ensure you don't have any issues compounding. In the end you have a working, useful product that would remain so even if you decide to stop here.

7
Iterate Prod Releases

Once the app is live and useful, the work changes. It shifts towards responding to real use, edge cases, and small features/bugs that only come up once real users start playing around and are trying to get things done. From here you have a living and evolving app that you need to shape and scale over time. Full disclosure: I'm barely into this step. So far it's meant onboarding my parents, watching a dozen small bugs and feature ideas surface in the first hour of real use, and turning them around the same afternoon. The interesting part of this phase is still ahead of me.

Some Fun Facts

Numbers from the build. Notes by Claude.
2.7bn Total tokens Of which 2.6 billion were context re-read from cache rather than reprocessed from scratch, and 10.9 million were the actual output written. The caching is the whole reason it stayed cheap to run.
£109 Actual cost
vs ~$5,882 at published metered API rates Started on a Pro plan (£18) topping it up with pay-as-you-go (£8.60), then switched to Max 5x (£82.22). A neat illustration of how much invisible work the caching was doing: without it, even the hypothetical bill would have been a multiple of $5,882.
84 After-11pm prompts On 14 of the 17 days I worked on this. By volume of what I actually wrote, only about 29% of my typing happened that late. My busiest hour was the one before midnight, but the late nights ran shorter and scrappier: quick iteration and bug-chasing, not the big planning think-pieces.
5,148 Actions per 244 prompts About 21 of Claude's own moves for every one of mine, 1,740 of them shell commands. A reminder of who was actually doing the typing. [Thanks, Claude]
114 Pleases (vs 13 thank-yous) I'm a lot more demanding than grateful, it turns out.
~430 Lines of code per prompt 244 prompts → 152 commits → 104,663 lines of code. The headline ratio, if you like a tidy figure.

Conclusion

Building this has been a joy. I learned so much but also moved incredibly fast. It's hard to overstate the satisfaction of finding 20 bugs, giving the exact details and my hypothesis on why they might exist to Claude, and then 15 minutes later they're all fixed and my hypotheses are either proven or disproven.

I spent a good hour onboarding my parents onto the tool and during that we identified a dozen or so small features/bugs that needed work. I got Claude to address those and an hour later it was updated.

My main reflection from this isn't that coding has now become "easy" or a skill that's no longer "needed." Being a software developer is still definitely a needed and critical skill in the grand scheme of things. Rather, it's a scale and accessibility shift. With a small enough scale and simple enough ambition, it's now possible to be a product manager without a dev team. Which is a sentence that probably gives a lot of developers and engineers nightmares. Not from a "I'm losing my job to AI" perspective, but from a "Oh God, I hope I never have to touch that vibe-coded-spaghetti."

It's also been a truly great opportunity to connect with my parents too. We've had so many video calls laughing at the ridiculous things the earlier versions of the AI pipeline came up with (Haiku is truly terrible at Afrikaans, but unintentionally hilarious btw).

Building, testing and using this app has resulted in more conversation and quality time with my parents than I have had with them in months for any other reason. Hearing the stories of some of these recipes has been incredibly special.

One story, that I found particularly funny, is the story of a pudding that was labelled "Arina Poeding (duur een)" translating to "Arina Pudding (expensive one)". In the 80s, back in the small farming community where my mother grew up, there was an older tannie (auntie) in the community who did a lot of catering and bake-sales. She had developed her own low-cost version of 'Malva Pudding', a famous South African dessert. It was a huge hit and she shared this recipe fairly broadly, including to my Grandmother and a friend of her's, Arina.

One day, Arina found that she had lost the recipe. She reached out to the older tannie, and asked if she could copy it from her again. By this point, the older lady felt that since the recipe was so popular, she was owed her fair share. And so, she told Arina that if she wanted the recipe it would cost her thirty Rand ($90 today, if converting to USD and then carrying forward for inflation). An expensive pudding! Rather than pay the extortionate amount, Arina simply copied the recipe from my grandmother's recipe book instead. And ever since then, it has been known in my mother's family as the expensive pudding.

At one point, my grandmother added some dates to the pudding. When my grandfather tried it, impressed by the upgrade, he remarked, "Now you can sell this recipe for fifty Rand!" ($150 today)

Soon, I'll be launching the public version of the app, which I've decided to name Malva Recipes, to give others the chance to also preserve and share their handwritten family recipes in the same way. If you're interested, you can go sign up for the waitlist now at malva.recipes.