I've been baking sourdough for a few months. Not years — months. I want to say that up front, because most of what's written about baker's percentage assumes you already know what it is and just want to argue about the third decimal place.
Here's the honest truth: I read about baker's percentage in maybe ten recipes and every writeup I could find, and none of it stuck. Flour is 100%, water is a percentage of flour, salt is a percentage of flour — fine, sure, I could recite the definitions. But when I stood at the counter with a scale and 500 grams of flour, I still couldn't tell you what a 20% starter actually was on the scale. The words weren't hitting my hands.
I didn't understand it until I built it.
Writing the formula — the actual code that turns "70% hydration + 20% starter + 2% salt" into "450 grams of flour, 300 grams of water, 100 grams of starter, 10 grams of salt" — was when it finally clicked. Because the code doesn't let you fudge. You have to say what a percentage is of, and what the starter contributes, and how to back it out when you weigh things into the bowl. Every question the code asked me was a question I hadn't been able to answer just from reading.
My first perfect Classic came right after that. Not because the calculator did the math for me — I could do the math on paper. It's because building the calculator made me finally see the math. The numbers stopped being abstract and started being flour.
This post is how that build actually went. Two evenings, one real bug, and a small tool that lives on the site now for anyone else who learns by making.
What I wanted before I wrote any code
I wrote the constraints down first, which is the single most useful habit I have as a developer. Not a spec — just a short list of things that were non-negotiable.
Grams by default. Most home bakers think in grams. They think "500 grams of flour," not "100% flour." Percentage mode is powerful and I wanted it, but if the first thing you see is a percentage field, you've already lost half the people who'd find this useful. Grams first, percentages one tap away.
Degrees F and C, site-wide. The temperature toggle in the header already existed for the recipes. Anything new I added had to respect it. Nothing worse than a site where half the pages know your preference and half don't.
It has to work on my phone, in a floury kitchen. This is the constraint that killed the most ideas. Big tap targets. No hover-only anything. No modal that needs two hands. If I can't operate it with one knuckle while the other hand is in the dough, it fails.
No signup. No ads. No email capture. It's a calculator. Nobody should have to make an account to divide by a hundred.
The build, honestly
I'll be plain about the process because I think people are cagey about this and it doesn't help anyone.
Evening one. I opened Cursor and used Claude to draft the first version as a React component. This took maybe forty minutes and produced something that worked — inputs, a totals table, live recalculation. It was the right shape almost immediately. That part genuinely was fast, and I don't want to undersell it.
But it was React, and the rest of my site is a Python script that spits out static HTML. Adding a build pipeline and a framework for one calculator page was the wrong trade. So that draft became a prototype, not the product. Which is fine — that's what prototypes are for.
Evening two. I brought it into Perplexity Computer and worked through the port to plain HTML and vanilla JavaScript. That session did the heavy lifting:
- Ported the whole component to a single JS file with no dependencies
- Added the grams/percent mode toggle, with grams as the default
- Wired up presets pulled from the recipes already on the site, so "Classic" or "Bagels" loads real numbers instead of made-up ones
- Added the deep-link chip — if you land on the calculator from a recipe page, there's a small link at the top that takes you back to the recipe you came from
That last one is my favorite detail and it's the least impressive technically. It's a query parameter and a lookup table. But it fixes a real irritation: you tap "scale this recipe," you get your numbers, and then you're stranded on a tool page trying to remember which loaf you were making.
Then I found the bug
Here's the part worth reading.
There are two ways people write baker's percentages when a sourdough starter is involved. Call them Method A and Method B.
Method A treats the starter as its own ingredient. Your flour line is the flour you weigh out, your water line is the water you weigh out, and the starter sits alongside them. Simple to read, but the true hydration of the dough is higher than the number printed on the page, because the starter is bringing its own water to the party.
Method B subtracts the starter's flour and water from the flour and water lines. Your printed percentages describe the actual dough. It's more accurate and it's what most serious references use, but it means the numbers on the page aren't the numbers on your scale unless the recipe says so explicitly.
The calculator was doing Method B. My recipe pages were written in Method A. Nobody had told me — I found it because I ran the Classic through my own tool and the hydration came out different from what the recipe page claimed. About four percentage points off. Not a catastrophe, but real, and exactly the kind of quiet wrong that erodes trust in a site.
The tool was right and the recipes were wrong. That's the worst possible version of a bug, because there's nothing to fix in the code.
I sat with it for a day. The easy fix was to make the calculator match the recipes. The correct fix was the other direction. So I converted every dough recipe on the site to Method B, added a note under each ingredients table explaining that the starter's flour and water are subtracted from the totals, and made the calculator's "what to weigh" section spell it out too. It took a full weekend and it was the single most valuable thing I did to this site.
What I actually learned about building with AI
I'm going to say two things that sound contradictory and are both true.
The first: this was dramatically faster than building it by hand. Two evenings versus what would have been a week. The models are very good at the shape of a problem — take this component, port it to vanilla JS, keep the behavior identical. That kind of translation work is where they shine and I'd use them for it again tomorrow.
The second: you have to test the math yourself, every time. Not read it — test it. Run known inputs, check known outputs, against a source you trust.
A model can generate wrong code that reads beautifully. Clean variable names, sensible comments, a tidy little function that computes the wrong number with total confidence.
Nothing in the output looks wrong. There's no syntax error, no red squiggle, no failing test unless you wrote the test. The only reason I caught the Method A / B mismatch is that I've weighed enough dough to know what 72% hydration is supposed to feel like in the bowl, and the number on the screen didn't match the feeling in my hands.
That's the honest takeaway. It took a baker's instinct plus a developer's paranoia. Either one alone would have shipped the bug.
If you're building with these tools — and you should be, they're good — hold onto the domain knowledge. That's the part that isn't automatable yet. The model can write the function. It can't taste the bread.
Go try it
The baker's percentage calculator is free, has no signup, and works on a phone. Load a preset, switch to percentages if that's how you think, and tell me if you find a number that looks wrong. I mean that — I'd rather hear about it than not.
If you're new to sourdough and the math has been slipping past you the way it did for me, don't feel bad. Build a version of your own if you have to. It's how I learned it.