First, the before photos

Before touching a line of CSS, we photographed everything. Partly for honesty — a redesign series that can't show its "before" is just a mood board — and partly because those photos turn out to be a working tool, not a keepsake. A quick Playwright script (it graduates into a proper harness in Part 3) captured all ten surfaces at their natural sizes: the booking page on a 375px phone, the kiosk on a tablet, the board and the staff pages at 1280.

Here is the waiting-room board — the screen that hangs on a wall and gets read from chairs:

A waiting-room TV wearing an app sidebar — with Register and Login links. Fourteen parts of engineering, and the room sees a developer template.

And the booking page, the screen a stressed parent meets on a phone:

Twenty-two identical buttons and no opinion about any of them. It works — season one proved that under test. It just doesn't care.

Two bugs before a single design decision

The before shoot was supposed to produce evidence. It produced findings. Look at that board screenshot again: the sidebar offers Register — and Register has been a 404 since Part 11's hostile review deleted the whole self-registration surface. Nobody removed the sidebar link. Which means the TV on the waiting-room wall spent the rest of season one offering patients a link to an error page, and it survived a test suite, a hostile security pass, and a deploy checklist — because all of those read code, and in code nothing is wrong. A link to a deleted page is perfectly valid markup. It's only wrong on a television. One photo caught it.

The second finding came from the kiosk:

The kiosk before-shot took two takes. The first run typed every seeded code and got "No appointment found" back — the demo appointments had quietly aged out, four days after Part 12's deploy. This green alert is the second take, after re-seeding.

The kiosk was being perfectly correct: those codes really did belong to appointments in the past, and refusing them is exactly what Part 11 would have demanded. But "correct" and "demo-able" are different claims, and demo data has a shelf life. Both bugs go in the log, both get fixed in the next two parts — and notice what found them: not a review prompt, not a test, a camera. Hold that thought until Part 3.

Why AI design converges on slop

Now the actual subject. Ask an AI to "make it look nice, modern and professional" and you will get the same app everyone else got: a purple gradient somewhere load-bearing, Inter on white, three feature cards with icons, generous rounded corners, a hero section congratulating you on visiting. This isn't a personality flaw — it's what a language model is. It predicts the likely continuation, and a generic prompt asks for the most likely design. A vague "make it nice" is, quite literally, a request for the average of the internet.

The trap has a second jaw. When the average design comes back, most of us can't articulate why it's wrong — "it looks AI-generated" isn't actionable feedback — so we ask for another pass, get a slightly different average, and settle. You can't art-direct what you can't name. The fix is to change the shape of the request so that naming happens up front.

The technique: propose wide, choose narrow

Instead of asking for a design, ask for directions — several of them, genuinely different, each pinned down hard enough to be judged. The ask is small; the constraints are the whole trick:

"Propose four visual directions for this app, and make them genuinely
different from each other. For each: a name, background / ink / accent
colors as hex, one typeface, and a single line on how it should feel.
No purple gradients, no default-font-on-white. Directions only — no
CSS yet."

Hex codes force commitment — "warm and inviting" is not falsifiable, #FAF7F2 is. One line of feel keeps each direction honest about what it's for. And "no CSS yet" is the same clause that made season one's security review work: proposals first, so the human stays the judge. Here are the four that came back, exactly as proposed:

The four directions, as proposed

Four real options, and now choosing is a human-sized job. B is a beautiful poster and a cold clinic. C is right for exactly one of our surfaces — remember it when the board gets its own dark treatment in Part 6 — and wrong for a family clinic's public pages. D risks twee the moment it meets staff-page density. A is clinic-appropriate warmth, works in light and dark, and its typeface is a story in itself. We picked A.

🧠 Model pick: Opus, high effort, for the directions. Divergence is a thinking task — asked for four directions, the cheap model tends to return one direction wearing four names. Everything else in this part (the before shoot, the revision below) is pennies on any model.

The human veto

This is where the part earns its title. Tokens were about to be built on Calm Practice when a nagging feeling produced the most valuable prompt of the season so far, verbatim: "it's not similar to my other project, right???" — three question marks, because the feeling was already pretty sure. We opened the stylesheets of my other project, UnifiedSelf, and checked: cream #F4F1E8, green #2C7A4B, sage #A8BDB6, Fraunces. Direction A — warm paper, sage primary, serif-adjacent warmth — was its near-twin. The "distinctive" direction was distinctive against the internet and derivative against my own portfolio.

🤖 What the AI got wrong: nothing it could have known — which is exactly the lesson. The model optimized "distinct from AI defaults" because that's what the prompt asked for and that's the corpus it can see. Your portfolio is the corpus it can't. "Distinctive" has two halves — distinct from the slop and distinct from your own prior work — and the second half is your job to bring: paste your other projects' palettes into the prompt, or expect a twin. The veto itself also doesn't delegate: the AI rated Calm Practice distinctive right up until it was shown otherwise.

v2: porcelain & petrol

The revision kept everything that was right about A — calm, light, accessible — and moved the hue away from my own shadow: cool instead of warm. "Calm Practice: porcelain & petrol" — porcelain #F5F8F8 background, white surfaces, ink #182A2D, petrol teal #16696F as the primary, coral #C96F4A as the accent, #3E8460 for good news and #B4473C for bad. The dark set was priced on day one rather than bolted on later: #101B1D background, #182527 surfaces, ink #E4EDEC, primary lifted to #4FB3B8.

The typeface survived both versions, and deserves its sentence: Atkinson Hyperlegible was designed by the Braille Institute for low-vision readers — its letterforms are deliberately unambiguous, so 1, l and I, or 0 and O, can't impersonate each other. A clinic's UI is read by anxious people, older people, and people squinting at a wall from five meters. That's an accessibility story built into a font choice, and Part 8 will hold the rest of the design to the same standard.

The plan for the season

Two strategy decisions are already made, and both come from treating the redesign like the engineering project it is. First, foundations before beauty: Part 2 builds a token system and — the migration trick of the season — deletes Bootstrap while keeping its class vocabulary, so every page keeps compiling. The kiosk and the board become chrome-free "appliances," which is also the structural fix for that Register link. Second, after Part 3 makes the screenshot loop a real tool, each surface gets its own part as its own UX discipline: phone, touch, signage, pro tool. Four surfaces, four different sets of rules — that's the argument of the whole series.

💸 The meter: season one closed at ≈ $6.20 total; season two's meter starts fresh. ≈ $0.40 so far — the before shoot, four directions, and the porcelain & petrol revision. The most valuable contribution of the part — "it's not similar to my other project, right???" — was typed by a human, free of charge.

✅ Checkpoint: git checkout part-12 in the repo is forever the before photo: the board wears its sidebar, the sidebar offers Register, and Register 404s. The before screenshots are committed under shots/before — the next nine parts argue against that folder.

Next, the foundation every later part will spend: every color a custom property, dark mode by redefining tokens instead of touching components, and Bootstrap deleted on the same day every page keeps compiling — Part 2: Foundations: design tokens, dark mode — and killing Bootstrap.

Originally published at coder000.com. Part of the series From Prompt to Polish — read the whole series there.

The bill, honestly

These numbers come straight from the build log — cumulative API spend as each part of the app landed:

What each part of ClinicLive cost in API spend

💸 The meter, final reading: ≈ $6.20 of API spend and roughly one hour of wall-clock AI-assisted building — for a Blazor Server app with PostgreSQL, two SignalR surfaces, auth, a nine-test suite against a real database, CI, and deploy artifacts. An honest estimate for hand-building the same thing: two to three days.

How the meter is measured, throughout this series: it's the build's actual token consumption priced at the API list rates of the models used (the 🧠 boxes name them). If you work through a subscription plan instead of pay-per-token, your bill won't say "$6.20" — but the tokens burned are the same, so it's the honest apples-to-apples number.

Now the honesty that belongs next to that callout: the $6.20 is not the real cost. The real cost is the human time steering and reviewing — reading every diff, pasting the schema into a review before accepting it, saying no to SMS, noticing that "Test G" isn't "Test G." That time doesn't appear on any meter, and it is precisely the part you must not skip — because every mistake in the next table was caught by exactly that time, and the one that wasn't caught early (open self-registration) sat in the codebase for six parts. The dollars buy drafts. The review is where the app became correct.

The complete mistake log

Every 🤖 from fourteen parts, in one table:

What the AI got wrong, part by part

Sort that table by kind and a pattern jumps out. Syntax barely features — two CS0542s across fourteen parts, both fixed in seconds, is the entire compiler-error tally. Where the AI actually failed was your context: business rules (the queue order lived in the spec, not the code), time (whose "today"?), auth reality (which connection carries which cookie), scope (what "version 1" means). The training data taught it the world's code; nothing taught it your clinic. And notice the repeats — the same CS0542 twice, the same confident tone before and after every mistake. It doesn't learn your lessons between sessions. You have to carry them.

🤖 What the AI got wrong: this whole post, condensed — almost never the syntax, reliably the context. Every mistake worth logging was about our rules, our timezone, our auth, our scope. That's not a flaw to wait out with better models; it's the permanent shape of the division of labor. The context is your job.

What the AI was brilliant at

Fairness cuts both ways, and the wins were not small:

• The scaffold. A complete Blazor Server solution with Identity, wired and running, in minutes. Nobody types that faster.
• The translation work. Spec to DDL, schema doc to EF Core entities, requirements to EditForms — mapping one precise representation onto another is its native gear.
• The test harness. The whole Testcontainers rig, and when told "no mocking library", a hand-written 30-line no-op IHubContext — a genuinely tasteful choice.
• The runbook. Part 12's DEPLOY.md, 2am checklist included, is better deployment documentation than most funded products ship.
• Explaining every error instantly. CS0542, "pending model changes", the 401 loop — each diagnosed and explained in seconds. As a tutor sitting inside your terminal, it has no precedent.

🧠 Model pick, the series rule: Opus-class where mistakes compound — the spec, the schema, the real-time design; Sonnet-class where the path is well-worn — the scaffold, CRUD, tests; cheap models for the mechanical. Fourteen parts never needed the rule revised: match spend to the consequence of error.

Saying "I built it with AI" in an interview

Done wrong, it sounds like a confession. Done right, it's a hiring signal — and the difference is entirely in the story you can tell. Here's the ClinicLive version: the spec came first, and the AI interviewed me before writing it. Every prompt is recorded in a commit message, so the process is reviewable end to end. The tests were written from the spec, not from the code — and I can explain the tautological-test trap that rule prevents. A hostile review pass caught open self-registration before it shipped. I read every diff.

That story demonstrates spec thinking, review discipline, testing judgment and security awareness — the things interviews are trying to detect. The fear behind the question was always "can this person function without the tool?", and a story about directing the tool answers it better than pretending you don't use one. If interviews are on your horizon, the interview prep hub is built for this, and the AI interview series' prompting part turns this series' habits into answers you can give under pressure.

Keeping sharp

The whole series' discipline, compressed to four lines worth pinning above your desk:

• Read every diff. No exceptions, no "it's probably fine".
• Hand-write something weekly. The day you can't write it is the day you can't review it.
• Own the spec. Deciding what "correct" means is never delegated.
• Never ship what you can't explain. If you can't explain it, it isn't yours yet.

✅ Checkpoint, the last one: you've shipped a real app with AI — spec to schema to SignalR to a VPS, tested against a real database, hardened, deployed, and honestly accounted for. That's not a tutorial completed; that's a capability. Here's what to build next: something of yours, same discipline, prompts in the commits.

Where next 🎉

And the story continues: ClinicLive works — but it still looks like the template it was born from. Season two, From Prompt to Polish, redesigns it with AI: a real design system, four surfaces treated as four UX disciplines, and before/after screenshots of every step. Season three, From Prompt to Pocket, then takes the same screens into a .NET MAUI app on Android and Windows — push notifications, haptics, a QR scanner and all.

Fourteen parts, one app, $6.20. If this series left you wanting to go deeper rather than wider: the Blazor series builds the UI-side fundamentals this series moved fast over, and the PostgreSQL series gives the database the attention it deserved here. And if the commit-messages-as-prompt-log trick appealed to you, that only works when git is second nature — the Git & GitHub workshop starts from the very beginning.

Got a war story — an app you built this way, a mistake your AI made that belongs in somebody's table? Tell me through the contact page. I read every message, and the best stories become posts.

The models in this series will be museum pieces in three years. The discipline won't: own the spec, read the diff, define correct, explain what you ship. The tools multiply judgment — so grow the judgment, and let them multiply it.

Thanks for building all fourteen parts with me. Now go build something of your own. 🤖

Originally published at coder000.com. Part of the series From Prompt to Production — read the whole series there.

Two ways to use AI for code

If you've never used AI tooling, here's the landscape in one paragraph. The first way is chat: you open a chat window, paste some code, ask a question, and copy the answer back into your editor. It works — plenty of developers learned a lot this way — but notice who's doing the manual labour. The model only knows what you paste, it can't run anything, and you are the clipboard, ferrying code back and forth and hoping you pasted enough context.

The second way is agentic: a tool that lives in your project folder, reads your files itself, proposes edits as reviewable diffs, runs your build and your tests, and asks permission before doing anything. You stop being the clipboard and become the reviewer — which, as we'll see, is the job that actually matters.

This series uses Claude Code, Anthropic's agentic tool. It comes in whichever shape suits you: a command-line tool, a desktop app for Mac and Windows, a web version at claude.ai/code, and IDE extensions for VS Code and JetBrains. Everything in this series works the same in all of them; we'll set it up properly in Part 2.

The method: prompt, review, refine, commit

Before tools and prices, the thing that actually decides whether AI development goes well. Everything we build in this series follows one loop:

(diagram on the original post — the AI development loop: you write a prompt, the AI writes code, you review and test it; problems loop back into a refined prompt, good code gets committed.)

You describe what you want and why. The AI writes code you didn't type. Then comes the step that separates professionals from headlines: you read it, run it, and test it. Code that isn't right doesn't get argued with — it feeds a sharper, smaller prompt. Code that is right gets committed in a small, reviewable piece. That's the whole method. Every part of this series is this loop, applied to a different problem, and the review step is the one we never skip.

Which model, when — and what it costs

"AI" isn't one thing you talk to; you choose a model per task, and the choice is mostly about money and thinking depth. Models are priced per token — roughly three-quarters of a word — and you pay separately for what the model reads (input) and what it writes (output). Here's the current Claude line-up:

Claude models, August 2026 — prices per million tokens (input / output)

Each model also takes an effort setting, from low to max, which controls how hard it thinks before answering. High effort on a hard problem buys real quality; high effort on "rename this variable" buys you a more expensive rename. Our rule of thumb, which the whole series follows:

The rule of thumb this series lives by

📝 Note: everything above is true as of August 2026. Models and prices churn faster than any other fact in this series — this is the one section you should re-check against current pricing before trusting the numbers. The method — match the model to the stakes of the task — outlives any price list.

🧠 Model pick: every part of this series opens its toolbox in a box like this one — which model, what effort, and why. This part is all reading, so nothing was billed to the build yet; the standing picks are the table above, and you'll see us follow it: Opus for the spec and schema in Parts 3–4, Sonnet for the scaffolding in Part 5.

Honest expectations

Here's the part most AI content skips. These tools are genuinely, sometimes shockingly good at a specific set of things:

• Boilerplate — the code you've written a hundred times and never enjoyed once: DTOs, mappings, configuration, test scaffolding.
• Translation between technologies — "this is how I did it in SQL Server, show me the PostgreSQL way" is a question AI answers better than most search results.
• First drafts — a working starting point in minutes, for you to shape.
• Explaining errors — paste a stack trace and get a plain-English account of what went wrong, and usually why.

And there's a set of things it reliably gets wrong, no matter how impressive it looks while doing them:

• Your business rules — the AI has never met your clinic, your users, or your edge cases. It will guess, confidently.
• Time zones — AI-written date handling that compiles and demos fine can still be quietly wrong about what "today" means. Ask us how we know (Part 10).
• Security defaults — it happily ships whatever a template ships, including the parts a hostile reviewer would circle in red (Part 11).
• Its own blind spots — it can't tell you what it doesn't know, and it repeats its habits. Wait until you see it make the exact same compiler error in two different parts.

🤖 What the AI got wrong: nothing yet — we haven't asked it for anything. But this box appears in every part, because keeping the mistakes in is the point of this series. Coming attractions, all real: an SMS feature nobody asked for (Part 3), timestamps without time zones (Part 4), a chat design that fails authentication forever (Part 8), and a test that passes because the code is wrong (Part 9). The human stays the pilot. That's not a disclaimer; it's the method.

What we're building: ClinicLive

A real app needs a real problem, so meet ClinicLive: front-desk software for a small clinic. Patients book a 15-minute appointment from their phone — no account, no password, just a short confirmation code. A tablet at the door lets them check in with that code. A waiting-room screen updates by itself the second someone checks in. And behind the login, reception and practitioners see today's schedule, call the next patient, and chat with each other — with presence and typing indicators — instead of shouting down the corridor.

(diagram on the original post — ClinicLive architecture: the booking page, check-in kiosk and waiting-room board talk to the Blazor Server app; the QueueHub pushes live updates out; EF Core persists everything to PostgreSQL.)

That little diagram is the whole build: three browser surfaces, one Blazor Server app, one PostgreSQL database, and SignalR pushing changes out so nobody ever presses refresh. It's small enough to finish and real enough to hurt — bookings can race, queues can be ordered wrong, and time zones can lie. Perfect.

The finished code lives in the companion repository at github.com/rahulvyas777/clinic-live, and it has one unusual property: every commit message contains the actual prompt that produced the commit. The repo's history is the series. From Part 3 onward there's a tag per part, so you can check out the code exactly as it stood at the end of any chapter.

What about Copilot, Cursor and the rest?

Alternatives absolutely exist — GitHub Copilot, Cursor, Google's Gemini CLI, and more arriving monthly — and they're good tools; the loop in the figure above applies to all of them. We use Claude Code for this series for an unexciting reason: going deep on one tool teaches you more than a survey of five, and depth is what you can carry to whichever tool your team ends up using. If your instinct is to comparison-shop first, our beginner's guide to AI-assisted coding surveys the field; this series is the deep end.

💸 The meter: our build so far: $0.00. Every part reports the running total, honestly. And a spoiler worth having up front: the entire fourteen-part build — spec, schema, features, real-time, tests, debugging, hardening and deployment — lands at about six dollars of model usage. Hold that number next to any hype you've heard, in either direction.

✅ Checkpoint: before Part 2 you should be able to say what separates chat from agentic tools, name which Claude model you'd pick for a schema design versus a mechanical rename, and sketch ClinicLive's three surfaces from memory. No installs yet — but having an Anthropic account ready (a paid Claude plan or API billing, either works) will make the next part a straight run.

The map is drawn. In Part 2, Claude Code goes onto your machine, learns your project's house rules from a file called CLAUDE.md, and makes its first change to real code — reviewed, understood, and committed like you mean it.

Originally published at coder000.com. Part of the series From Prompt to Production — read the whole series there.

About $17. Building ClinicLive with Claude Code cost ≈ $17.00 of API spend across 36 parts and three seasons: $6.20 for a shipped Blazor Server app, $3.60 for its redesign, and $7.20 for a .NET MAUI companion app on three hosts — with 28 tests green at the end and three public tag ranges in the repo so you can check out any moment of it. One caveat before anything else, in the words of the footnote every retro carries: on a subscription plan your bill won't literally say $17 — but the tokens burned are the same, so it's the honest apples-to-apples number.

The meter, all three seasons

Here is every reading on one chart. The top row is what each part added; the bottom row is the trilogy's running total, which starts at forty cents for a spec and stops at seventeen dollars for a signed APK.

(chart on the original post — API spend per part across the three ClinicLive seasons, with the trilogy's running total underneath. Season one, 14 parts, $6.20; season two, 10 parts, $3.60; season three, 12 parts, $7.20. The running total climbs from $0.40 at season one's spec to \(17.00 at season three's ship-it part. The most expensive single reading is season three's Parts 1 and 2 together, at \)1.30.)

Three things jump out before any table. First, no part cost more than $1.30, and most cost less than a dollar — the tallest bars are the parts that opened a season, where the architecture decisions and a lot of screenshots happen at once. Second, the seasons are more alike than different: the redesign was the cheapest, but not by the margin "it's only CSS" would predict, because a model looking at screenshots is burning image tokens. Third, the dead ends are in there. Season one's failed first chat design, season three's Windows toast chase and its forty-minute hunt for a QR poster the emulator never drew — all billed at the same rate as the features, and all left in the number on purpose.

Season by season

What each season cost, and what it shipped

"Per part" divides by every part of a season, including the ones that built nothing — the intros, season one's power-moves tour, and the three retros. Divide by the parts that actually moved the meter and the numbers are $0.62, $0.40 and $0.72. Either way, the honest unit is "less than a coffee per part."

Where the numbers come from

Three retros, reconciled. Season one's retro lists a running total for each of Parts 3 to 12, and the build log agrees with it to the cent. Season two's retro merged Parts 1–2 and 3–4 into two rows because the log only recorded a reading at Parts 2 and 4; the per-part numbers for Parts 1 and 3 below ($0.40, then $1.30 on the running meter) come from those parts' own 💸 boxes, which the retro didn't repeat. Season three's retro has Part 1 riding inside Part 2's reading, because the plan had no commit and its smoke build landed in Part 2. Nothing here is a new measurement — it's the same 29 readings, laid end to end.

Which model did what, and what the split cost

Every part opened with a 🧠 box naming its model, and the rule never changed across three seasons: Opus where a mistake would compound — a spec, a schema, real-time semantics, a diagnosis, a review — and Sonnet where the path was well-worn: scaffolding, CRUD, tests, CSS, a documented toolchain. Here is how that rule played out, part by part, with what each part added to the meter.

Model per part across all 36 parts, and what each part added

Season one · From Prompt to Production

Season two · From Prompt to Polish

Season three · From Prompt to Pocket

Add it up by lead model and the split is even in count and uneven in cost. Fifteen Opus-led parts cost $10.10, about $0.67 each. Fifteen Sonnet-led parts cost $6.90, about $0.46 each — $0.49 if you leave out season one's setup part, which cost effectively nothing. Six parts have no reading of their own. So the thinking model's parts cost about half as much again, and less of that gap than you'd guess is the price list: the Opus parts were also the ones with the long design conversations, the failed first attempts and the most screenshots.

One honesty note about that arithmetic. The log records one reading per part, not one per model. Where a part used both — most of season three did — the whole reading is counted under the model its 🧠 box leads with, the one that made the part's defining call. That is a judgment, and season three's scanner part is the closest one.

🧠 The rule, unchanged for 36 parts: match the spend to the consequence of error, not to the difficulty of the typing. Season one put it as "where mistakes compound"; season two as "what is this surface?"; season three as "semantics — foreground versus background versus stopped." Same rule, three axes. It never needed revising, and the table above is the receipt.

What caught the AI's mistakes

The three retros keep a mistake table each: eight rows holding 14 mistakes for season one, 6 for season two, and 44 rows for season three, one of which is an honest "no code catch" rather than a mistake. The later two tables record what caught each one; season one's has no such column, so its 14 are classified here from the descriptions. Tallied together:

What caught each of the 63 logged mistakes, by season

The honest reading is that the tools people assume catch AI mistakes caught the fewest. The compiler and the build found ten of sixty-three, and most were fixed in minutes — CS0542 twice, an ambiguous View, a DLL lock, a runtime pack that doesn't exist. Tests found four, and three of those were the test being wrong rather than the code. The two catchers that found forty of the sixty-three were a screenshot and a person. The screenshot loop found a sidebar on a TV, an error banner on every page, a status bar the wrong color, a phone that had quietly given up reconnecting — things no diff can show. A person found the rest, from a spec that invented SMS, to a palette that was a near-twin of the author's other project, to a captured desktop that should never have been captured. Season one's shape is different for a reason: with no screenshot loop yet, its catches came from reading code against a spec, which is why "a human" carries nine of its fourteen.

Two fairness notes. Tests look weak in this tally and were the strongest thing in the trilogy: the nine written in season one stayed green through a redesign that touched every page, and the 28 at the end are why a phone, a desk and a browser could share one set of rules without anyone re-checking them by hand. Catching mistakes and preventing them are different jobs. And nothing in the table was free: screenshots are image tokens, and the person is not on the meter at all — which is the next section.

What the money did not buy

Human time is not on the meter. Say it plainly, because the $17 headline invites the wrong conclusion. The meter counts tokens; it does not count reading every diff before accepting it, pasting a schema into a review, judging four art directions, vetoing a palette, toggling airplane mode, reading a vibrator log, or looking at a screenshot before writing its caption. Season one estimated its own wall-clock at roughly an hour of AI-assisted building against two to three days by hand — and even that hour sits beside the review time the retro called "the real cost," like the twenty minutes of human reading that Part 5 said was the most expensive thing in it. Seasons two and three never logged hours at all; their retros say where the time went instead: "most of it is the looking," and "the meter bought code; the proving is where the season went." If you want a real cost per part, add your own hours to the $0.47.

The bench. An Android emulator, a Windows desktop, a free-tier Firebase project, a PostgreSQL in Testcontainers, a Playwright harness that photographs every surface, and a screenshot script that learned — the hard way, twice — to refuse a frame it doesn't own. None of that is a token, and season three's retro is clear that the bench, not the model, is where that season went.

Three things the bench couldn't prove. Windows toast notifications never displayed: registration succeeds, the setting says Enabled, and no banner appears, because an unpackaged app has no identity and the series declined to fake an MSIX. No on-device QR decode was photographed, because the emulator never rendered its posters; the chain is proven by a test instead — everything except the lens. And Google Maps launched and crashed on the emulator after the directions intent resolved. Season three's retro keeps all three together, and $7.20 closed none of them.

What was never built. iOS compiles and was never built, for want of a Mac. Patient accounts and SMS, which the spec said no to in Part 3 and kept saying no to. A packaged Windows build. Anything a real phone does after the emulator's Maps died.

The judgment. The most valuable lines in the trilogy were typed by a person before the model started, and cost nothing: the spec's non-goals; the rule that a test is written from the spec, never from the code; "who uses this surface, and what state do they find it in?"; "a second front door must not grow a second set of rules"; "stale means read-only"; "fake nothing." Each would have shipped as something plausible and worse without it. The dollars bought drafts; those sentences are why the drafts became an app.

How the meter is measured

Every retro carries the same footnote under its bill, with its own season's number in it. Here it is exactly as season three's retro prints it — the 🧠 boxes it refers to are the per-part model picks summarized in the table above:

How the meter is measured: the build's actual token consumption priced at the API list rates of the models used (the 🧠 boxes name them). On a subscription plan your bill won't literally say $7.20 — but the tokens burned are the same, so it's the honest apples-to-apples number.

Two details that follow from it. The tokens include every image the model looked at, which is why screenshot-heavy parts cost more than their code would suggest. And every reading was written down at ten-cent precision as its part landed, which is why every number in this post wears a ≈.

Frequently asked

How much does it cost to build an app with Claude Code?

For ClinicLive it was about $17 of API spend across 36 parts: $6.20 for a Blazor Server app with PostgreSQL, SignalR and tests, $3.60 for a complete redesign, and $7.20 for a .NET MAUI companion app on Android, Windows and the web. That is actual token consumption priced at API list rates; the human time spent reviewing and testing is not included.

Is Opus or Sonnet cheaper for AI-assisted development?

In this build the fifteen Sonnet-led parts averaged about \(0.46 each and the fifteen Opus-led parts about \)0.67, but the choice was made by consequence of error, not price: Opus for specs, schemas, real-time semantics, diagnosis and reviews; Sonnet for scaffolding, CRUD, tests, CSS and documented toolchains.

What catches the mistakes in AI-generated code?

Across 63 logged mistakes in three seasons, screenshots caught 21, a human reading or looking caught 19, the compiler or a failing build caught 10, running the app caught 8, tests caught 4 and CI caught 1. The compiler and tests are necessary, but most of the catching was done by looking at the running result and by a person.

What does the $17 not include?

Human time: reading every diff, reviewing screenshots, running an emulator and a device bench, and deciding what correct means. It also leaves out the hardware and accounts used, three things the bench could not prove, and an iOS build that was never made.

If you want the stories behind the numbers, the three retros have them: what ClinicLive really cost, what a redesign really costs, and what a companion app really costs. And each season starts where its Part 1 does: From Prompt to Production, From Prompt to Polish, and From Prompt to Pocket. Thirty-six parts, one app, about seventeen dollars — and a great deal of looking that no meter ever saw.

Originally published at coder000.com. It sums up the ClinicLive trilogy — From Prompt to Production, From Prompt to Polish and From Prompt to Pocket — read the whole series there.