DEV Community: Rahul Vyas

From Prompt to Pocket: One App for Phone, Desk and Browser

Rahul Vyas — Mon, 21 Sep 2026 14:00:00 +0000

Season one, From Prompt to Production, built ClinicLive: a clinic books appointments, checks patients in at a kiosk, and calls them from a live waiting-room board. Season two, From Prompt to Polish, made it look like someone meant it. Both seasons ended with the same person in the same chair — the patient, staring at a TV on a wall. This third and final season puts the queue in their pocket: one set of Blazor screens for an Android phone, a Windows desk and a browser, built with the same AI pair, twelve parts, every dead end kept in.

Android (Part 9)

Windows (Part 10)

Where the season ends, shown first so you know what you're building: one Home component, rendered by the Android emulator in Part 9 (light theme, four tabs, a remembered visit) and by the Windows app in Part 10 (dark theme, the side rail, five tabs — the Waiting room arrives that part). Each app follows its host's theme. The white area to the right of and below the Windows frame is the capture, not the app.

Why the patient deserves an app

The board from season two's Part 6 is genuinely good signage — if you're in the room. Real waiting rooms leak: people step out to the car park, take a toddler for a walk, go to the pharmacy next door, and come back to find their name was called three minutes ago. A companion app fixes the part the wall can't: check in from the car park, watch your place in the queue move, feel a buzz when you're next, and — the one that matters most — get a push notification when it's your turn even if the app is closed. Plus the boring essentials: where the clinic is, how far away you are, one tap for directions.

Notice what's not on that list. Booking stays on the website; the ticket you get there carries a six-character confirmation code, and that code is the whole credential — no account, no password, exactly as season one decided. The app is a companion to a visit that already exists, and keeping its scope that small is the first design decision of the season.

Hybrid, web or native: the honest trade

Three ways to put ClinicLive on a phone, and each has a real cost.

A responsive website. We already have one, and it works on a phone. What it can't easily do is the pocket part: vibrate, ask for a notification permission at the right moment, reach a closed app, open the camera to scan a ticket. Some of that is possible on the web with enough work (Web Push, in particular), but it's a different project and, honestly, not the one we're doing.

Fully native. Kotlin for Android, Swift for iOS, something else again for Windows. Three codebases for a team of one developer and one AI, and every Razor component from two seasons thrown away. Native gets the best result per platform; it also multiplies everything by three.

.NET MAUI Blazor Hybrid, which is what we picked. A MAUI app hosts a BlazorWebView; your Razor components render inside it, but the C# runs natively on the device in the .NET runtime — no Blazor Server circuit, no WebAssembly download. The UI is HTML and CSS you already know, and the device is one C# call away: haptics, notifications, GPS, the camera, secure storage. The trade is that the WebView is exactly that — a web view. Anything the OS owns (the status bar, the gesture bar, the safe area, the system font) is the OS's business, not your stylesheet's. Part 2's very first screenshot is a lesson in that sentence.

One set of screens, three hosts

The architecture is the argument of the season, so here it is before a single prompt. The maui-blazor-web template gives you three projects; we add a fourth:

The four projects — where things live, and why

Project	What's in it	Rule
`ClinicLive.Contracts`	The DTOs the phone and the server agree on	Share the shape of the data, never the server's code
`ClinicLive.Pocket.Shared`	Every screen, once — a Razor Class Library	Nothing in here references a platform API directly
`ClinicLive.Pocket`	The MAUI host: Android and Windows (iOS compiles; see below)	Answers the shared code's questions with what the device has
`ClinicLive.Pocket.Web`	A Blazor Server host for the same components	Answers the same questions, honestly, as a browser

"Answers the shared code's questions" is the pattern every native feature in this season follows, and it's simple enough to show in full now. The shared project declares an interface; each host implements it with whatever it actually has. This is the first one, and its comment is the design rationale:

/// <summary>
/// The first "capability interface" — the pattern every native feature in this app follows.
///
/// The shared UI asks the question ("what am I running on?"); each host answers it with
/// what it actually has. MAUI answers from DeviceInfo; the web host answers "a browser".
/// Nothing in the shared project ever references a platform API directly.
/// </summary>
public interface IPlatformInfo
{
    /// <summary>"Android", "Windows", "iOS", "Web"…</summary>
    string Platform { get; }

    /// <summary>OS version string, for the About screen and bug reports.</summary>
    string Version { get; }

    /// <summary>Phone-sized screen — drives the "one hand, thumbs" layout choices.</summary>
    bool IsPhone { get; }

    /// <summary>"Native app" or "Browser" — which host is rendering these components.</summary>
    string Host { get; }
}

Nine of these arrive over the season — platform info, app lifecycle, haptics, notifications, push registration, location, the camera scanner, connectivity and storage — and the browser host implements every one of them, sometimes as an honest no-op ("not here"). That honesty is the point: the shared screen never has to know which host it's on, and a feature the browser can't do simply doesn't render. The web host also earns its keep as a development tool — it's the host the season-two screenshot harness can already photograph.

The toolchain, and one bug before a single prompt

Nothing exotic was installed for this season. Visual Studio's MAUI workloads were already on the machine, with the Android SDK and an emulator: a Pixel 5 image running Android 13, the Play-services flavor so Firebase can deliver push later. That emulator is the phone in every Android screenshot you'll see; the Windows app runs on the same PC; the browser host runs under the same Playwright harness that photographed season two. Docker still provides PostgreSQL, exactly as in season one.

The first smoke build of the untouched template found the season's first bug, and it wasn't in the template. Android built. The web host built. The Windows target failed with MSB3030 — "could not copy" a Windows App SDK file with a very long name — through three retries, a self-contained flag and a clean of obj/. The cause was the folder: the scratch path was about 270 characters long, and the Windows App SDK's copy step dies quietly past Windows' 260-character MAX_PATH. The same project in a short folder built in 9.9 seconds.

🤖 What the AI got wrong: it spent three retries and two configuration changes on a build that was failing for a reason no configuration touches. The lesson to carry: "works on Android, fails on Windows" can be your folder name. When one target of a multi-target project fails on a file operation, look at the path before the project.

What this season does not cover

Here's the part most tutorial series skip. Four things are out of scope, and three more will turn out to be things the bench could not prove — you'll meet each one where it happens, but you deserve the list up front.

iOS builds. The MAUI project targets iOS and Mac Catalyst and they compile — but there is no Mac on this bench, so nothing was ever built or run on Apple hardware. Every iOS file you'll see in the repo is an honest stub that says so.
Store publishing. Part 11 produces a signed APK and app bundle for Android and a self-contained Windows folder. Nothing goes to a store.
Web Push. The browser host gets everything except push; that's a project of its own.
MSIX signing. The Windows app ships unpackaged. Part 11 explains what a packaged identity would buy — and why that matters for the next item.

And three limits the season ran into and kept, rather than faked: Windows toast notifications never displayed in this season (the permission said "Allowed", the code returned success, no banner — Part 5 finds it, Parts 10 and 11 explain it); the Android emulator never rendered the poster a QR scanner needs, so the on-device decode in Part 8 is proven by a round-trip test rather than a photograph; and Google Maps on the emulator crashed after our directions intent had done its job (Part 7). The screenshots of all three are in the posts, exactly as they came out.

📝 Perishable facts, as of September 2026: this season was built with Claude Code, picking a model per part — Claude Opus 5 at high effort for the judgment calls (architecture, lifecycle semantics, diagnosing the Android insets, deciding what not to fake), currently $5 in / $25 out per million tokens, and Claude Sonnet 5 at medium effort for the plumbing, currently $3 / $15. The app targets .NET 10 and MAUI 10; the emulator runs Android 13. Prices and model names churn faster than anything else in this series — re-check them before trusting the numbers. The method — match the model to the stakes of the task — is the part that lasts.

🧠 Model pick: every part opens its toolbox in a box like this one. The standing rule from season one still holds: Opus, high effort, where a wrong decision is expensive to undo — Part 2's project structure and capability interfaces, Part 4's reconnect and resume semantics, Part 6's foreground-versus-closed push rules; Sonnet, medium, where the rules are already settled and the work is plumbing — the API in Part 3, geolocation in Part 7, the desk layout in Part 10, shipping in Part 11.

💸 The meter: season one closed at ≈ $6.20 and season two at ≈ $3.60; season three's meter starts fresh. Nothing is on it yet except the smoke build above, which lands in Part 2's number. A spoiler worth having up front: the whole season — three hosts, push, haptics, GPS, a camera, offline, signing and CI — comes in at about $7.20 of model usage, with two dead ends responsible for more of that than any feature.

✅ Checkpoint: there's no tag for this part — nothing was committed yet. Before Part 2 you want the MAUI workload installed, an Android emulator that boots (any recent Android will do; ours is Android 13), and season one's PostgreSQL container ready, since the clinic itself is the server the app will talk to. The repo tags this season pocket-02 through pocket-11, one per build part, and the series page lists all twelve.

Next: the template goes in, the template comes out, the season-two tokens move into a phone-first stylesheet, the first capability interface proves the three hosts are really rendering the same component — and the first Android screenshot catches a purple status bar and a header hidden under it. Part 2: One UI, Three Hosts: The Capability-Interface Pattern.

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

The Polish Retro: What a Redesign Really Costs

Rahul Vyas — Fri, 18 Sep 2026 14:00:00 +0000

Ten parts ago, ClinicLive worked but looked like the template it was born from. This series made the sequel promise: redesign it with AI and hide nothing — every direction debated, every design mistake kept, every dollar counted, and a screenshot of everything. The meter has stopped. Time to look at what we made.

The gallery

This is the payoff post, so the pictures go first. Every "before" is part-12 — the app exactly as season one shipped it. Every "after" is the tagged part where that surface got its treatment.

Before

After

The board. Before: a web page on a TV, sidebar included — with a Register link that 404'd. After: signage — its own permanent dark palette, a 13vmin serving name readable from the back row, a real clock, and status shown only when something's wrong.

Before

After

Booking, at 375px. Before: a form. After: a flow — slot chips grouped morning/afternoon, thumb-sized targets, phone keyboards wired via input types, and a submit button that says "Book 16:45" instead of "Submit."

Before

After

The staff queue. Before: timestamps nobody computes with. After: a live stat header and a WAITED column that turns red past 20 minutes — the number reception actually manages by, computed by the software instead of in reception's head.

Before

After

The kiosk. Before: a login form wearing a different label. After: a stage — 3rem letter-spaced code entry, one giant button, and (off camera) a success takeover that auto-resets after eight seconds for the next stranger in line.

Before

After

Staff chat. Before: a log file with a send button. After: a chat that reads like one — bubbles, mine on the right, presence dots — and, since Part 9, one that follows its own conversation.

The ticket has no "before" pair, because there was no ticket — season one confirmed bookings with a paragraph. Turning the confirmation into an object worth screenshotting was Part 4's best idea.

The bill, honestly

Same rules as season one's retro: cumulative API spend from the build log as each part landed. The log kept running totals at each milestone, so Parts 1 and 3 — the direction exercise and the screenshot harness — ride inside their neighbors' readings:

What each part of the redesign cost in API spend (cumulative)

Part	What we designed	Running total
1–2	Four directions and a choice; the porcelain-and-petrol tokens; Bootstrap deleted	≈ $1.10
3–4	The screenshot harness; the booking flow and the ticket	≈ $1.60
5	Kiosk: giant code entry, success takeover, auto-reset	≈ $2.00
6	Board: signage palette, vmin sizing, the clock	≈ $2.50
7	Staff: stat headers, the WAITED column, chat bubbles	≈ $2.90
8	Live regions, landmarks, skip link, the contrast audit	≈ $3.20
9	Motion that explains change; the nine-line interop file	≈ $3.60

💸 The meter, final reading: ≈ $3.60 for the entire redesign — a design system, four surfaces treated as four UX disciplines, an accessibility pass and a motion pass. Season one's $6.20 built ClinicLive working; $3.60 more made it something people would want to use. The redesign cost barely half the build — and it changed almost everything a user actually touches.

How the meter is measured, same as season one: 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 literally say "$3.60" — but the tokens burned are the same, so it's the honest apples-to-apples number.

And the same caveat as last time, because it's still true: the dollars are not the real cost. The real cost is the human eye — every screenshot reviewed, every direction judged, one palette vetoed outright. The meter buys drafts; the looking is where it became a design. Keep that in mind as you read the next table, because most of it is the looking.

The complete design-mistake log

Every 🤖 from ten parts, in one table:

What the AI got wrong, part by part

Part	What went wrong	Caught by
1 — before shots	The waiting-room TV wore the app's sidebar — including a Register link that 404'd, because season one's hardening pass deleted the page and nobody deleted the link. Six parts of code review missed it.	The first screenshot
1 — before shots	The demo data had aged out: seeded appointments were four days stale, and the kiosk correctly refused their codes. "Correct" and "demo-able" are different properties, and screenshots test the second one.	The screenshot loop
1 — direction	The winning "Calm Practice" palette was a near-twin of the author's other project — same warm cream, same greens. The AI checks its output against the world's defaults, not against your own portfolio; it has no idea what else you've shipped. Version two became porcelain and petrol.	The human — nothing else could
2 — foundations	Every `h1` wore a teal focus ring — `FocusOnNavigate` focuses the heading for screen readers, and the new global `:focus-visible` rule happily styled it. Fix: rings on interactive elements only.	The screenshot loop
2 — foundations	"An unhandled error has occurred" visible on every page. The deleted template CSS had been quietly carrying `#blazor-error-ui { display:none }` — the invisible parts of a template are still load-bearing.	The screenshot loop
2 — foundations	The new top bar wrapped into three awkward rows at 375px — fine at every width the AI had "seen," broken at the one patients use.	The phone-width screenshot

Read the right-hand column and season two's pattern appears, and it's different from season one's. There, the mistakes were about context — your rules, your timezone — and the catches came from reading code against a spec. Here, almost every catch came from looking at rendered output: the screenshot loop from Part 3 found things code review is structurally blind to, because no diff shows you a sidebar on a TV. And the one mistake the loop could never catch — the near-twin palette — needed a reviewer with something no model has: a memory of your own portfolio.

What the AI never caught alone

The mistake table undersells the human half, because the biggest contributions weren't corrections — they were direction. The AI proposed four art directions; a person chose Calm Practice and then vetoed its first palette. The WAITED column — the best feature of the staff redesign — arrived only after a human asked "what number does the person at the desk actually act on?" The kiosk's auto-reset came from "who uses this surface, and what state do they find it in?" In every case the AI executed beautifully once the question existed — and would have shipped something plausible and worse if it hadn't.

🤖 What the AI got wrong: the season in one sentence — it never had taste, it had defaults. Left unprompted it converges on the same purple-gradient slop Part 1 opened with; pointed at a surface with the right question, it produces work you'd pay a studio for. The AI executes judgment; it doesn't replace it. Your questions are the design.

What the AI was brilliant at

Fairness cuts both ways, and season two's wins were real:

The vocabulary migration. Deleting Bootstrap while every page kept compiling — by inventorying the forty classes actually used and reimplementing them on the tokens — was the season's best engineering trick, executed flawlessly. A redesign that never breaks the build is a redesign you can ship incrementally.
Per-surface reframing. Asked "who uses this, standing where?", it re-derived each surface from first principles: vmin sizing for a wall TV, a success takeover for people standing up, density for people paid to scan. The four-disciplines structure of this series came out of those answers.
The copy pass. "Mornings fill up first." "That email doesn't look right — or leave it empty." "Stuck? The front desk is right there." Microcopy this humane usually requires a writer on staff; here it required asking.
Tireless iteration. The screenshot loop ran dozens of look-adjust-reshoot rounds. A human designer's patience is a budget; the model's isn't. It never once defended a bad draft out of ego.

🧠 Model pick, the season's rule: Opus wherever the question was "what is this surface?" — the token system, the four directions, the board's signage reframing; Sonnet wherever execution ran against a settled system — booking, kiosk, staff pages, the motion pass. Same principle as season one, different axis: in design, the consequence of a cheap-model mistake isn't data loss, it's incoherence.

The tests postscript

One more number, and it might be the most persuasive one in the series: all nine tests from season one stayed green through the entire redesign — every part, polish-02 through polish-09, verified by the same CI. Ten parts of touching every page, deleting a CSS framework, rewriting every layout — and the harness built in season one silently guaranteed that none of it changed what the app does. That's the compounding return on testing nobody mentions: the suite you build in season one is what makes season two safe to attempt. A redesign with no tests is a rewrite with better marketing.

✅ Checkpoint, the last one: you've now shipped a designed app — not just working, but chosen: a token system with a portfolio-checked palette, four surfaces treated as four disciplines, announced to screen readers, explained through motion, and honestly accounted for. Here's what's next: run this season's loop on an app of yours. Before shots first — you can't see how far you've come without them.

Where next 🎉

Ten parts, one redesign, $3.60. The whole two-season arc — every prompt, every tag — lives in the ClinicLive repo, and the README's season-two tag table maps each polish-* tag to its part, so you can check out any moment of the redesign and see it with your own eyes.

If you arrived here through the design door, the story starts one season earlier: From Prompt to Production, Part 1 builds the app this series just polished, spec to VPS, mistakes and all. The full catalog of everything on this site is on the series page.

And the story continues: ClinicLive works and it's polished — but it lives on a kiosk and a wall. Season three, From Prompt to Pocket, puts it in the patient's pocket: the same Blazor screens as a .NET MAUI app on Android and Windows and as a web app, with real push notifications, haptics, geolocation, a QR scanner and offline support — every native feature a capability interface, every screenshot from a real emulator and a real desktop, every dead end kept in.

One closing thought to carry off. Season one proved AI can build software with you; this season proved it can design it with you — but only steered. The slop everyone recognizes isn't what the models produce; it's what they produce unquestioned. Four directions instead of one default. A screenshot instead of a hope. "Who uses this, standing where?" instead of "make it pretty." The tools bring the polish — you bring the taste, and this series' real deliverable was the habit of insisting on it.

Thanks for seeing the redesign through, all ten parts of it. Now go make something of yours worth screenshotting. 🎨

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

AI UI Design Without the Slop: Four Directions and a Choice

Rahul Vyas — Mon, 14 Sep 2026 14:00:00 +0000

Season one of this story, From Prompt to Production, ended with a retrospective and a working app: ClinicLive books appointments, checks patients in at a kiosk, and calls them from a live waiting-room board — tested, hardened, deployed. It also looks exactly like the template it was born from. This series is the design sequel: same repo, same AI pair, ten parts to close the gap between "works" and "looks like someone meant it."

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

	Direction	Palette & type	Feels like
A	Calm Practice	Warm paper `#FAF7F2`, ink `#1F2A2E`, sage `#5B8A72`, clay `#C4664B` for warnings · Atkinson Hyperlegible	A practice you trust
B	Swiss Health	Pure white, near-black, a single red `#D32F2F` accent, hard grid · Helvetica stack	Precision, zero warmth
C	Night Shift	Dark-first slate `#16181D`, cyan `#4DD0E1`, glowing board	Mission control
D	Friendly Paper	Cream, rounded everything, Fraunces serif accents	A children's clinic

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 Retro: What ClinicLive Really Cost, and What the AI Got Wrong

Rahul Vyas — Fri, 11 Sep 2026 14:00:00 +0000

Fourteen parts ago, this series made a promise: build a real app with AI and hide nothing — every prompt shown, every mistake kept, every dollar counted. ClinicLive is live behind nginx, its commit messages are the prompt log, and the meter has stopped. Time to count.

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

Part	What we built	Running total
3	The spec (plus 9 clarifying questions)	≈ $0.40
4	PostgreSQL schema	≈ $0.60
5	Blazor Server skeleton, entities, migration, seeder	≈ $1.10
6	The booking flow	≈ $1.80
7	Live queue: kiosk, board, SignalR hub	≈ $2.70
8	Staff chat, presence, typing	≈ $3.40
9	Test suite vs a real PostgreSQL	≈ $4.10
10	Two real bug hunts	≈ $4.90
11	The hardening pass	≈ $5.60
12	Deploy runbook, nginx, systemd, CI	≈ $6.20

💸 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

Part	What the AI got wrong
3 — spec	Invented an SMS notification feature nobody asked for; wanted patient accounts until the non-goal was stated explicitly. Scope creep is a habit, not an accident.
4 — schema	`timestamp` without a timezone; no index on the `appointment.patient_id` foreign key; a plain UNIQUE on the slot that would have blocked re-booking a cancelled appointment. The partial-index requirement had to come from us.
5 — skeleton	Left the SQLite package in the csproj "for tests"; didn't flag that the template's confirmed-account default would lock out every seeded staff login until we asked "why can't I log in?"
6 — booking	Treated clinic hours as UTC — wrong "today" for any clinic east of UTC, slot labels shifted by the offset. Compiled, demoed fine, quietly wrong about time. Fixed in Part 10.
7 — queue	CS0542: injected a `QueueService Queue` member into `Queue.razor` — a component can't have a member named after its own class.
8 — chat	Proposed an `[Authorize]` hub that a server-side component can never reach (the connection carries no browser cookie — 401 forever). And CS0542 again, Chat in `Chat.razor`.
9 — tests	Wrote the queue-order test by reading the code instead of the spec — a tautological test that passed against a bug. Also asserted "Test G" where the board masks to "Test G."
11 — hardening	The template's open self-registration had shipped unquestioned in Part 5: anyone on the network could create an account and walk into the staff area. Found only when we made the AI attack its own app.

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.

AI-Assisted Development in 2026: Tools, Models and Honest Expectations

Rahul Vyas — Mon, 07 Sep 2026 14:00:00 +0000

Over the next fourteen parts we're going to build one real application — a clinic booking-and-queue system with Blazor Server, PostgreSQL and SignalR — and an AI is going to write most of the code. We'll show every prompt, keep every mistake in, and count every dollar. This first part is the map: the tools, the models, and what you can honestly expect before we type a single prompt.

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)

Model	Price in / out	What it's for
Claude Opus 5	$5 / $25	The deep-work default: hard design, debugging, code review
Claude Sonnet 5	$3 / $15	The everyday coding workhorse
Claude Haiku 4.5	$1 / $5	Quick questions and mechanical edits

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

The task	The pick	Because
Writing a spec, designing a schema, reviewing code	Opus, high effort	Mistakes here compound for months; thinking is cheap by comparison
CRUD features, scaffolding, tests	Sonnet	Well-trodden ground; the workhorse handles it
"Rename this everywhere", formatting, tiny edits	Haiku	Mechanical work deserves mechanical prices

📝 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.

What Building a Real App with AI Actually Cost: 36 Parts, Three Seasons, About $17

Rahul Vyas — Fri, 04 Sep 2026 01:07:45 +0000

Three seasons, thirty-six parts, one clinic app — and a meter that ran the whole time. Every part of the ClinicLive trilogy ended with a 💸 box, every retro added its season up, and every number came from the build log rather than from memory. This post puts all of it in one place: what the whole thing cost, part by part and model by model, what caught the AI's mistakes, and what the money could not buy.

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

Season	Parts	Total	Per part	What shipped
One · From Prompt to Production	14	≈ $6.20	≈ $0.44	A Blazor Server app: PostgreSQL schema, booking, a live queue and board over SignalR, staff chat, nine tests against a real database, a hardening pass, an nginx and systemd deploy, CI (`part-03` to `part-12`)
Two · From Prompt to Polish	10	≈ $3.60	≈ $0.36	A token-based design system with dark mode, Bootstrap deleted, four surfaces redesigned as four UX disciplines, an accessibility pass and a motion pass — nine tests still green (`polish-02` to `polish-09`)
Three · From Prompt to Pocket	12	≈ $7.20	≈ $0.60	A .NET MAUI Blazor Hybrid companion app on Android, Windows and the web: nine capability interfaces, a live queue, push, haptics, geolocation, a QR scanner, offline; a signed APK, a self-contained Windows build, CI — 28 tests (`pocket-02` to `pocket-11`)
The trilogy	36	≈ $17.00	≈ $0.47	One app, three seasons, everything above

"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

Part	What it built	Model	Why	Added
1	The landscape — reading, no build	—	Nothing billed	$0.00
2	Claude Code setup, a two-line change	Sonnet	Everyday work	≈ $0
3	The spec, nine clarifying questions	Opus	Decisions that compound	$0.40
4	PostgreSQL schema	Opus	Decisions that compound	$0.20
5	Skeleton, entities, migration, seeder	Sonnet	Mechanical, well-trodden	$0.50
6	The booking flow	Sonnet	CRUD on a written spec	$0.70
7	Live queue: kiosk, board, SignalR hub	Opus	Real-time semantics	$0.90
8	Staff chat, presence, typing	Opus	One architectural judgment	$0.70
9	Tests against a real PostgreSQL	Sonnet	Mechanical scaffolding	$0.70
10	Two bug hunts	Opus	Diagnosis	$0.80
11	The hardening pass	Opus	Adversarial review	$0.70
12	Runbook, nginx, systemd, CI	Sonnet	Documented territory	$0.60
13	Power moves — built nothing	—	Nothing billed	—
14	The retro	—	Nothing billed	—

Season two · From Prompt to Polish

Part	What it built	Model	Why	Added
1	Before shots, four directions, a veto	Opus	Divergence is a thinking task	$0.40
2	Tokens, dark mode, Bootstrap deleted	Opus; Sonnet for the CSS	Structure and taste	$0.70
3	The screenshot harness	Sonnet	Bread-and-butter code	$0.20
4	Booking flow and the ticket	Sonnet	Execution on a settled system	$0.30
5	Kiosk: code entry, success takeover	Sonnet	Execution on a settled system	$0.40
6	Board as signage	Opus	"What is this surface?"	$0.50
7	Staff pages, the WAITED column	Sonnet	Execution on a settled system	$0.40
8	Accessibility audit and fixes	Opus	Adversarial reading	$0.30
9	Motion that explains change	Sonnet	Execution on settled rules	$0.40
10	The retro	—	Nothing billed	—

Season three · From Prompt to Pocket

Part	What it built	Model	Why	Added
1	The plan and a smoke build	—	Rides inside Part 2	—
2	Contracts, shared RCL, two hosts, insets	Opus; Sonnet for the stylesheet	Architecture and a diagnosis	$1.30 (with Part 1)
3	The API, the client, the Visit screen	Sonnet; Opus for one call	Plumbing on settled rules	$0.60
4	SignalR on the phone, lifecycle, reconnect	Opus; Sonnet for the page	Connection semantics	$0.70
5	Haptics, notifications, the Windows dead end	Opus; Sonnet for the platform bodies	Product decisions	$0.80
6	Firebase push to a closed app	Opus; Sonnet for the bindings	Stopped-state semantics	$0.80
7	Geolocation and maps	Sonnet; Opus for two things	Essentials did the work	$0.50
8	QR on the ticket, the native scanner	Opus for two judgments; Sonnet for the rest	A native page over the WebView	$0.90
9	Connectivity, two-tier storage, the cached visit	Sonnet; Opus for two decisions	Plumbing	$0.50
10	A desk-sized window, one breakpoint	Sonnet	CSS and a window size	$0.40
11	Signed Android, Windows publish, CI	Sonnet; Opus for what not to fake	Toolchain plumbing	$0.70
12	The retro	—	Nothing billed	—

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

Caught by	Season one	Season two	Season three	Total
A screenshot	0	5	16	21
A human reading or looking	9	1	9	19
The compiler or a failing build	2	0	8	10
Running it: the app, a log, the emulator	2	0	6	8
A test	1	0	3	4
CI	0	0	1	1
Mistakes logged	14	6	43	63

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.