The initial design sat for two years
About three weeks from restarting to the App Store.About three weeks from Claude to shipped
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.
User study a 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.Three asked butter for single swaps. 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.
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.Nobody had run into a limit, or even pushed near it. That is mine to fix, not theirs. The redesign made butter’s range visible from the recipe screen.
What it cost
I built capability into butter and failed to make it visible.
Capability that can’t be seen from the surface it lives on may as well not be built yet.
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
Decisions v1 → 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.
02 why 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
03 why 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.
The free plan caps the collection, not the quality.
butter costs money every time it answers, so the free plan has two limits: four chats a day, and fifteen recipes.
Fifteen caps what you keep, not what you do with it. Variations are free and unlimited. Chats reset every morning.
Charging for development would have been charging for the thing the product is for.
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.”
Usage metrics coming soon.
The original concept stored recipes. The shipped product helps bakers develop them.
2026bakebook: recipe lab, on the App StoreiOS free
Explore 2024 design
2024: Concept through hi-fi design
Six weeks
Bakers change things across attempts: ingredients, method, timing. Those changes are the first thing to get lost. I designed bakebook around that loop.
Study 01 what 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, 32 home 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 02 what 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 for accessibility and busy hands, then scoped out for a later release.
wireframe
This wireframe came after the questionnaire. Sharing is still in it. I had thought of it first, and that took a while to let go of.
hi-fi
