Bakers weren’t looking for another place to store recipes. They needed to remember what changed between bakes.
Six weeksresearch through final UI
Recipe apps store recipes. Almost none help you develop one.
Bakers change things across attempts: ingredients, method, timing. Those changes are the first thing to get lost. I designed bakebook around that loop.
- 01Understand7 bakersJune 2024Questionnaire, hobby bakers to pastry chefs
- 02Prototype5 bakersJuly 2024Moderated usability test
- 03Live product5 bakersJul–Aug 2026One week in the live app
Study 01what the questionnaire decided
- Asking
- How do you save, change, scale, and come back to a recipe?
Cut
A social recipe feed.
- public posting
- comments
- likes
- saving other people’s recipes off a wall
interest ratingfrom the few who had any
I wrote it into the concept before I asked anyone. Seven answers ended it, and it was never built.
Kept
Recipes lived on notepads and scraps, and got lost.
“I generally write down recipes on notepads and scraps of paper because I know I’m going to make corrections. Then I tend to lose track of the recipe later.”
Steve, 32home bakera searchable library
They changed recipes mid-bake, then forgot what they’d changed.
the Log Book
Scaling and substituting created uncertainty they Googled their way out of.
scalingunit flexibilityeventually butter
They weren’t trying to publish recipes. They were trying not to lose their own work.
Study 02what testing found
- Tasks
- Add a new recipe, revise it, then scale it.
Layer oneBuilt
Somewhere to keep a recipe
Structured storage: recipes, versions, variations, the Log Book.
What the test showedBakers built a recipe without help. Two asked for the Log Book without being prompted.
Layer twoDidn’t exist
Help changing a recipe
Nothing could read a whole recipe and answer what happens if I change this.
What the test showedAll five left the app to look up substitutions, then came back and typed the answer in by hand.
I worked out what the app was made of before I designed a single screen.
Empty screen to finished recipe, in four steps.
Voice was designed in, then scoped out for a later release.
Two years later
I came back able to build it.
About three weeks from restarting to the App Store.
Building it myself changed how I designed. I stopped asking what would be good to have and started asking what the data has to look like.
Study 03a week in the live app
butter worked. That was the problem.
Three of the five asked butter for single swaps: I’m out of sour cream, can I use buttermilk? They got good answers every time. Two never opened it. Then one found out it could read her whole tiramisu recipe and tell her how to push it brighter. It had been able to do that all week.
Nobody had run into a limit. Every easy question got answered, and no one pushed for a harder one. That is mine to fix, not theirs. The redesign made butter’s range visible from the recipe screen.
They were reading the app before they ever opened it.
“More like making a recipe vegan, or gluten-free.”a baker, asked what she thought butter was for
BeforeTerracotta and a friendly serif said grandma’s recipe book: cozy and homemade, not a lab.
ProblemThat identity made butter feel narrower and softer than the product actually was.
What it was
Fraunces + Nunitonine warm neutrals, a serif with history
DecisionA midpoint between precise and warm reads lukewarm, so each got a job: teal and mono hold the structure, cream and sans hold the soul.
the tablespoon lines on a stick of butter
→
the redraw ships in the next release, untested so far
- structure
- #007E9C
- ink
- #1E1714
- accent
- #A8432B
- ground
- #F6F4EE
Source Code Pro + Source Sans 3together they read as a lab book
Decisionsv1 → v2
Data model
A variation isn’t a different type of object. It’s a recipe with a parent.
Variation { … }
Recipe { parentId → Recipe }
Variations started as a separate object, then immediately needed everything recipes already had: scaling, notes, versions. Keeping two models meant building every feature twice.
Users see a file inside a folder. Underneath it’s the same object.
Assistant
butter needed memory before it could give better answers.
02why it changed
Bakers develop a recipe on and off over weeks. An assistant that forgets the thread is useless for iteration, so the conversation had to become a stored object. That is why the conversations tab exists: it came out of a storage decision, not a UI one.
butter now reads
- the recipe
- its versions
- its variations
- the conversation history
A thread can be picked back up three weeks later.
Navigation
Categories were a filter wearing a page's clothes.
The only one I shipped before I cut it
03why it changed
I knew while I was rebuilding it that categories didn’t deserve a destination. I kept it anyway, because I wanted to watch it working before I took it out.
The home screen’s most valuable pixels should serve the highest-frequency action, browsing and opening recipes, not a filing system you touch occasionally.
In the 2026 study, import-from-photos and quick scaling were both named unprompted as favorites. One baker called it something she was “very excited to use as I perfect my recipes for the farmers market.”
No usage metrics yet. The app is new, and I’d rather say that than dress it up.
The original concept stored recipes. The shipped product helps bakers develop them.
2026bakebook: recipe lab, on the App StoreiOSfree
What it cost
I built capability I failed to make visible.
Capability that can’t be seen from the surface it lives on may as well not be built yet.
Built with
- Design
- Figma · Illustrator
- Front end
- HTML · CSS · JavaScript, no framework
- App shell
- Capacitor · Xcode
- Backend
- Firebase: Auth, Firestore, Cloud Storage, Cloud Functions, Hosting
- butter
- Claude Sonnet via the Anthropic API, proxied through a Cloud Function so the key never reaches the device
- Development
- Claude Code
- Shipped via
- TestFlight · App Store Connect