The Engineer Becomes the Editor

I built GroceryTrack — web, iOS, and Android — by myself, in three months, for about $725 of AI tooling and under $45/month to run. The full story of what it does and how it's wired is its own post. This one is about a quieter thing the project kept teaching me: AI didn't just change how fast I could ship. It changed what I think engineering leadership should optimize for.

The through-line is simple. The bottleneck moved from writing code to judging it — and once that moves, the whole job moves with it, for an individual engineer and for the person leading thirty of them.

Capital Moved From Headcount to Judgment

Here is the cost structure of the entire product, stripped to two numbers:

The model writing the code costs five to ten times more than the model serving every user. That inversion is the headline most people miss when they talk about AI and software. We spent a decade assuming the expensive part of software was operating it at scale. For a small AI product, the expensive part is producing it — and "producing" now means directing and reviewing a model, not typing.

Read that as a leadership statement and it gets uncomfortable in a useful way. If the cost of turning a clear specification into working software is collapsing toward the price of the tokens, then the scarce, expensive resource on an engineering team is no longer the capacity to produce code. It's the judgment to decide what's worth producing, and the discipline to catch what the machine got confidently wrong. Capital shifts from headcount-to-build toward judgment-to-direct. That is a different thing to hire for, measure, and protect.

At Ninety Percent, the Engineer Becomes the Editor

Most of GroceryTrack's code was written by a model with me directing — Claude Code as the primary agent, with Gemini and Codex in rotation, because a second model is often the fastest reviewer of the first one's output. Call it the ninety-percent tier: the model does the bulk, and my job becomes writing the spec, reading the diff, and catching the mistake the model made with total confidence.

That last part doesn't shrink as the model gets better. It grows. The faster code gets produced, the more the binding constraint becomes how much of it a competent human can actually judge per hour. Review throughput, not authoring speed, is the new ceiling.

For an individual contributor, this rewards taste over output. For a leader, it rewrites the scorecard. Lines shipped and tickets closed were always weak proxies; at the ninety-percent tier they're nearly meaningless, because the model can generate either one on demand. What I'd actually measure on a team now is the quality of specs going in and the rigor of review coming out — the two human-shaped bottlenecks the model can't yet remove. The senior engineer's leverage stops being how much they can build and becomes how well they can direct and verify a machine that builds faster than anyone can read.

The Demo Was Free. The Production System Was the Whole Job.

A multimodal model reading a crumpled receipt is a five-minute demo. Shipping it to strangers is everything wrapped around that model call — and that wrapping, not the prompt, is where the engineering actually lives.

GroceryTrack's extraction path assumes the model will sometimes be confidently wrong, and is built to catch it: schema validation on every response, sanity rules that encode domain truths the model doesn't carry, retry logic for malformed output, and Sentry watching every failure so I see it before a user reports it. The sharpest example is a date. An early user's receipt printed 26/05/13 — YY/MM/DD — and the model read it as DD/MM/YY and filed her groceries years into the past. A human never doubts a grocery receipt's date; a model has to be told receipts come from the recent past. That one report became a validation rule that's held for every user since.

Three months in, I can put numbers on it. In the first week of reliable v1.3.0 tracking — 63 receipts, 792 line items, real users, me excluded — the engine cleared a usable parse 95.5% of the time and extracted line items at 97.9% accuracy:

But the headline hides the real lesson, and it's in the gap between those rows. By error rate, the weak fields aren't the items — they're the receipt headers. The thing a person glances at and trusts, the date and the store name, is what the model gets wrong most often, four to five times more than any individual line item.

Two honesty notes, because a number like 97.9% should make you suspicious. First, "accurate" here means "the user didn't correct it" — a genuine lower bound on error, since anyone who misses a mistake counts as a success. Second, I can only measure my camera path at all: email-forwarded receipts are parsed server-side and emit no client event, so right now I can't score them. Knowing exactly where my own measurement stops is more useful to me than a cleaner number would be.

That last point is the part that transfers. The model is cheap; judgment about where it fails is the scarce resource. The senior work was never writing the parser — the model writes the parser. It's deciding which outputs get validated, which domain truths get hard-coded as guardrails, and which fields a model is never allowed to persist unsupervised. At n=1, those are my own commits. At thirty engineers, they're exactly where I'd want review attention concentrated — and where I'd refuse to let "the model handles it" be the end of the conversation.

The Hardest Decisions Were the Ones to Not Build

When producing software gets cheap, the constraint stops being can we build it and becomes should we. That sounds obvious. It is brutally hard to live by, because the cost of saying yes has dropped and the temptation to add has never been higher.

GroceryTrack's clearest example is its own paywall. About three percent of trials convert to Pro. The reflexive move — the one every growth playbook recommends — is to optimize the funnel: tune the paywall, add urgency, A/B the copy. For an early-stage product that's the wrong instinct. Conversion optimization assumes the value is already there and you're just leaking it at checkout; this early there's almost nothing to tune, and squeezing the funnel would only manufacture a number that flatters me. The three percent matters for the opposite reason — not as a funnel to fix but as a referendum on value. Payment is the one piece of feedback users can't fake; it's how they vote, in the only currency that costs them something. Three people in a hundred voting yes is real signal that the product is worth paying for to a narrow slice — and the ninety-seven voting no tell me, more honestly than any survey could, that photographing every receipt is a high-discipline habit most people won't adopt, and that the insights aren't yet worth four dollars a month to them. No amount of paywall copy changes that verdict. The honest response is to fix the core loop until more people vote yes, or accept the size of the niche — not to chase a conversion number as if it were a dial to turn rather than a reading to heed.

I made the same call on platforms — and then on the project as a whole. Maintaining genuine feature parity across web, iOS, and Android as a solo builder is a tax that compounds forever, so chasing it was never the plan. Once Android ships and proves the cross-platform architecture, GroceryTrack moves into a deliberately minimal mode: I keep working on it, but I cap myself to under five hours a month and watch the running cost closely, because at this stage the marginal feature doesn't justify open-ended maintenance. That's not a failure to finish. It's a deliberate decision about where my scarcest resource — my own attention — goes.

This is the muscle I most want from a senior engineer and rarely see: prolific builders add; leaders subtract. And the thing that earns you the right to subtract is data you've actually looked at honestly. The three percent didn't tell me to try harder on conversion. It told me to stop.

Architecture Choices Are Staffing Decisions

Every layer of GroceryTrack runs on deliberately boring, managed infrastructure — Firestore, Cloud Run, Firebase, Stripe, Resend, Sentry. Nothing exotic, and that's the point. Shipping v1 in a day was only possible because none of my time went into plumbing that a managed service does better than I would.

For a solo builder, "use boring managed infrastructure" reads as a productivity tip. It's actually the same instinct as a staffing decision. Choosing not to run my own auth, my own queue, my own error tracking is the one-person version of not assigning a team to undifferentiated plumbing. The one place I did spend real architectural thought — splitting the latency-sensitive scan path from the batch path so a backlog of summary emails can never slow down someone scanning a receipt in their kitchen — is the one place the decision was actually differentiating. Build where it matters, buy where it doesn't. At n=1 that's a stack diagram. At scale it's a headcount plan, and it's the same judgment either way.

What This Changes About Leading Thirty Engineers

I lead a team in my day job, and I've spent years on the unglamorous work of consolidating sprawl into something coherent. GroceryTrack didn't teach me leadership. It gave me a controlled, single-variable experiment in what AI does to the shape of the work — and the answer is that it pushes every part of the job toward judgment.

Concretely, here's what I'd carry into running a team in this era. Bring the AI toolchain in deliberately, as a productivity multiplier, and be honest that its real cost is review, not tokens. Restructure the workflow around specs and verification, because those are the bottlenecks the model can't remove. Default to boring, managed infrastructure and spend the team's scarcest attention only where the work is differentiating. And protect the discipline of subtraction hardest of all, because it's the first thing to erode when building gets cheap.

What I Don't Know Yet

I'd be lying if I dressed this up as proven. It's n=1. A solo project is not an organization, and the habits that work when I'm the only stakeholder may not survive contact with twelve other opinions. The retention signal I care about is real but small — a few dozen strangers, not a market. My accuracy numbers are a lower bound from a one-week window, not a benchmark. And there's a whole category of decisions — the ambiguous architectural bets, the calls that trade one team's velocity for another's, the judgment about which problem is even worth solving — that the model can't touch, and that I suspect it won't for a long time.

That's the part I find genuinely interesting, and it's the part I'd want to talk about with anyone thinking about how engineering teams should actually work from here. The model writes the code now. Deciding what's worth writing, and catching what it got wrong, is still the whole job.