DEV Community: Rahul Vyas

The Pocket Retro: What a Companion App Really Costs

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

Eleven parts ago, ClinicLive lived on a kiosk and a wall. This season made the trilogy's third promise: put it in the patient's pocket with AI assistance and hide nothing — every prompt verbatim, every native feature behind an interface each host answers honestly, every screenshot from a real emulator or a real desktop, every dead end kept in. The meter has stopped. Time to look at what we made, and at what we couldn't prove.

The gallery

This is the payoff post, so the pictures go first. The season's claim was one set of screens, three hosts, so wherever the bench allowed it, a row is the same Razor component photographed on a phone, on a desk and in a browser.

Phone

Desk

Browser

Home. Part 2's phone and browser frames beside Part 10's desk frame — dark because the desktop's OS theme is, and the tokens follow it. Same component; only the width and the host's answers change.

Phone

Desk

Browser

The capability-interface pattern, photographed: one Settings.razor asks IPlatformInfo where it is and prints the answer. The Windows frame is from Part 5 — the phone-layout-on-a-monitor era — and it shows.

Phone

Desk

Browser

The waiting room, Part 10: Ava C. being served, Noah B. next, on all three — the desk and the browser both wearing the rail that one 900-pixel media query hands to anything wide enough.

Phone

The wall TV

Part 3's moment: Maria checked in from a phone and appeared on the TV built two seasons earlier, because the app's check-in is literally the kiosk's method. That Refresh button died in Part 4.

Part 5

Part 7

Part 8

Permission in context, three times: notifications at check-in, location on "Use my location", the camera on "Scan my ticket". Never at launch. The dialogs are Android's; the timing is ours.

Before the fix

After

Part 4's evidence. Left: a full minute after the server came back, the default reconnect policy had given up for good. Right: the keep-trying policy — 2, 4, 8, 16 seconds, then every 30, never null. A browser tab gets refreshed; a phone in a car park doesn't.

The ticket

The scanner

Part 8: a QR on the ticket and a native ZXing page pushed over the Blazor WebView. The camera is looking at the emulator's virtual living room, not at a ticket — more on that below.

Offline

Back online

Part 9: a code in the keystore, a queue state cached with the time it was true. Stale means read-only — you can see the button but you can't press it.

The bill, honestly

Same rules as season one's retro and season two's: cumulative API spend from the build log as each part landed. Part 1 was the plan, with no commit, so it rides inside Part 2's reading:

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

Part	What we built	Running total
1–2	The plan; contracts, the shared RCL, two hosts, the first capability; Android's insets	≈ $1.30
3	`/api/pocket`, the typed client, the real Visit screen	≈ $1.90
4	The phone joins the hub; lifecycle; the reconnect that never gives up	≈ $2.60
5	Two verbs of haptics, notifications in context — and the Windows dead end	≈ $3.40
6	Firebase push to a closed app; the stopped-state lesson	≈ $4.20
7	Geolocation, a testable haversine, package visibility	≈ $4.70
8	QR on the ticket, the native scanner — and the poster hunt	≈ $5.60
9	Connectivity, two-tier storage, the remembered and cached visit	≈ $6.10
10	A desk-sized window, one breakpoint, the waiting-room page	≈ $6.50
11	Signed Android, self-contained Windows, CI, the runbook	≈ $7.20

💸 The meter, final reading: ≈ $7.20 for the whole companion app — nine capability interfaces, three hosts, real push, real haptics, a real scanner, offline, a signed build and CI. Season one's $6.20 built ClinicLive; season two's $3.60 designed it; $7.20 put it in a pocket. Seventeen dollars for the trilogy. The two big dead ends — Part 5's toast chase and Part 8's poster hunt — are in that number; everything else was proportionate.

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.

And the caveat, one last time, because it was truer this season than either before: the dollars are not the real cost. The real cost was the bench — a GPS fix to fake, airplane mode to toggle, a vibrator log to read, a Firebase console to watch, a desktop to photograph without photographing anything else. The meter bought code; the proving is where the season went.

The complete mistake log

Every 🤖 from eleven parts in one table, including two that were about the process, not the code:

What the AI got wrong, part by part

Part	What went wrong	Caught by
1 — setup	The Windows target failed with MSB3030 copying a Windows App SDK DLL. The scratch path was about 270 characters; the App SDK's copy step dies silently past MAX_PATH. Ten seconds to build at a short path.	A shorter folder name
2 — hosts	A purple status bar: the template's `colors.xml` still painted it. CSS tokens don't reach Android's window chrome.	The first Android screenshot
2 — hosts	Header and tab labels missing on Android: the WebView draws under the system bars and `env(safe-area-inset-*)` reads 0 inside it. Fixed natively with an insets listener.	The Android shot beside the Windows one
2 — hosts	`View` is ambiguous inside a MAUI project.	The compiler
2 — hosts	The h1 focus ring was back on Windows — `FocusOnNavigate`'s `tabindex="-1"` matched the ring rule. Season two's bug, new face.	The Windows screenshot
2 — hosts	The web host served every static file empty: no environment set means Production, and `MapStaticAssets` wanted published assets.	A screenshot that looked like 1996
2 — hosts	The harness passed `-nologo` into the app's own arguments; Chromium screenshotted a directory listing.	The screenshot
2 — hosts	The Windows window opened maximized with the phone layout stretched across a 4K monitor. Deferred to Part 10.	The screenshot
3 — API	The "tomorrow" test booked the slot season one's booking test owns in the shared fixture; the old test went red.	The old test
3 — API	`postgres:18` images refuse a volume at the old data path; compose stopped working.	Compose failing to start
3 — API	Builds failed on DLL locks while the hosts were still running.	The build
3 — API	`--no-launch-profile` means Production — for the server, no demo seed.	An empty API
4 — live	Cold start grew from about 4 s to 7.5 s with the SignalR client; adb taps at four seconds were dropped. A slow app looked like a broken one.	logcat
4 — live	The emulator dimmed for inactivity. Gray screenshots, no bug.	A gray screenshot, then skepticism
4 — live	"Now serving David C.." — the masked name already ends with a full stop.	The screenshot
4 — live	Part 2's insets code left two warnings.	The compiler
4 — live	A minute after the server came back, the phone still said "reconnecting…": `WithAutomaticReconnect()` gives up after four tries, forever. Replaced with a keep-trying policy.	The screenshot a minute after restart
5 — nudges	Windows toasts never displayed: registration OK, setting Enabled, `Show()` returned, no banner — even a PowerShell toast to that identity was silent. Open all season.	The "Allowed, nothing shown" screenshot
5 — nudges	Windows reported haptics "available" — `IsSupported` is optimistic on a desktop. Cosmetic.	The Settings screenshot
5 — process	The first full-screen capture photographed the entire desktop, every other window included. Deleted before any commit; the harness now refuses full-screen unless the app is maximized, and excludes the taskbar.	A human, looking before committing
5 — process	A "diagnostic" Notepad the harness opened was a tab in the user's own Notepad window — Windows 11 Notepad is single-instance — and closing it closed theirs. Never automate other people's apps.	The person whose window it was
6 — push	D8: `FragmentKt` defined twice — Firebase's fragment-ktx 1.8.8 against MAUI 10's 1.9.0. Pinned.	The build
6 — push	"App closed" was simulated with `am force-stop`: Firebase said 1 delivered, the phone showed nothing. Force-stop is Android's stopped state, where push is never delivered; swiping an app away isn't. Redone with HOME plus `am kill`.	A phone showing nothing after "1 delivered"
6 — push	"Push is on" missing from the first shot — the token round-trip takes seconds. Not a bug.	An early screenshot
6 — push	Two identical "You're next": the check-in reload and the hub reload raced. Loads serialized.	The notification shade
6 — push	`IsInForeground` defaulted to true; a process Firebase starts has no window at all.	Reading the closed-app path
7 — location	"No maps app" with Google Maps installed: Android 11's package visibility needs a `<queries>` block in the manifest.	The screenshot, with Maps right there
7 — location	Maps then launched and crashed — the emulator's stale build. The intent resolved; the crash was photographed, not hidden.	The emulator
7 — location	The test asserted Greenwich to the Eiffel Tower is about 341 km; the haversine's 333.8 was right. The expectation was fixed, not the formula.	A failing test, checked by hand
7 — location	Test builds blocked by the running server's DLL lock.	The build
8 — scanner	The emulator never rendered its QR posters — forty minutes sweeping the room. A limit of the bench; the decode is proven by a test instead.	Forty minutes of looking
8 — scanner	The first web ticket shot was mid-animation, QR not yet loaded. The harness now waits.	The screenshot
8 — scanner	`.CacheOutput()` without output-cache middleware — swapped for a Cache-Control header before it could throw.	Review, before runtime
8 — scanner	`[A-HJ-NP-Z2-9]` let the banned L back in — J to N spans J, K, L, M, N — so a cereal-box URL parsed as ticket CEREAL.	The new test
8 — scanner	ZXing.Net and ZXing.ImageSharp both define `BarcodeReader<T>`.	The compiler
9 — offline	`SecureStorage.GetAsync` throws after a keystore reset; Home would have crashed on a restored phone.	Reading the restore path
9 — offline	Storage read in `OnInitialized` — no browser under the web host's prerender. Moved to `OnAfterRender`.	The web host
9 — offline	The native checkbox was Android-blue against petrol. One `accent-color` line.	The Android screenshot
10 — desk	No code catch. The honest entry is what stayed unfixed — toasts, because the answer is identity, not C#.	Named, not fixed
10 — process	The narrow-window frame was re-shot later, and the file that came back was not the app: Windows had refused the script's request to bring the window forward, so the capture copied whatever was in front of it — an unrelated window. Deleted before any commit; the harness now refuses to shoot unless the app window is in front and owns every corner of the frame.	A human, looking at the image before writing its caption
11 — ship	`-r win-x64` makes NuGet restore every target for that runtime, and Android's Mono runtime has no win-x64 pack (NU1102). Drop the flag.	The restore
11 — ship	The MSIX build reported success and produced no sideloadable package outside `obj/`.	Looking in the output folder
11 — ship	`apksigner.bat` exits non-zero after printing the certificates; the harness read "failed" for a success.	Reading the output, not the exit code
11 — ship (after publishing)	The workflow's first real run failed its Android job with `NETSDK1147`: it installed the `android` workload, and a MAUI project needs `maui-android`. One word, fixed on top of the tag; the re-run passed on all three targets.	The first real CI run

Read the right-hand column and a third pattern appears. Season one's mistakes were about context — your rules, your timezone — and were caught by reading code against a spec. Season two's were about looking, and the screenshot loop caught them. This season's were about the platform underneath the code: insets, stopped states, package visibility, MAX_PATH, restore semantics, exit codes. Almost none are visible in a diff, and a screenshot alone often wasn't enough either — the catch needed a screenshot plus a skeptic: a gray frame that was only a dimmed emulator, a "1 delivered" that meant nothing, an exit code that lied in both directions. The two process rows cost no tokens and taught the most: a screenshot harness needs a privacy guard, not just a crop, and it must never touch a window it didn't open.

What the AI never caught alone

The table undersells the human half again, because the biggest contributions were decisions, and this season they lived in the prompts. Two verbs of haptics, because an app that vibrates for everything gets muted. Permission at check-in, never at launch. "A second front door must not grow a second set of rules." "The code is the credential." "Stale means read-only." "Prove as much as the bench allows" and its twin, "fake nothing." Each was a sentence a person wrote before the model started, and each would have shipped as something plausible and worse without it. The two process incidents were human catches too: the model doesn't know what else is on your desktop, or whose Notepad that is. And Part 7's wrong "known distance" was caught by a test the model wrote but decided by a human working the numbers by hand — a failing test is a question, not an order.

🤖 What the AI got wrong, the season in one sentence: it knew the APIs and not the platform. It wrote NotificationCompat from memory and didn't know a force-stopped app never receives a push; it wired a ZXing camera view in an afternoon and didn't know the emulator couldn't show it a poster; it signed an APK and didn't know apksigner exits non-zero on success. Platform knowledge only comes from being bitten — and a bench, a log and a skeptic are how you get bitten on purpose, cheaply, before a patient does.

What the AI was brilliant at

Fairness cuts both ways, and this season's wins were the biggest of the three:

The capability-interface pattern, nine times over. From IPlatformInfo to IAppStorage, each a small interface in the shared project, answered by MAUI next to the platform it talks to and by the web host honestly — null, false, "not here". Introduced once in Part 2, never bent, so the screens never learned which host they were on.
Diagnoses that would have cost a person a day. Safe-area insets reading zero inside a WebView. A 270-character path killing a Windows build. Android 11's package visibility. The AndroidX version dance. Each named from a screenshot or a build log of the symptom.
Proof by other means. When the emulator couldn't be shown a QR, it proposed the test that decodes the server's PNG back through the parser — the whole chain except the lens. When no screenshot can show a vibration, it went to the OS's vibrator log: 182 ms, 102 ms, 403 ms. It looked for evidence instead of settling for a claim.
Honest no-ops. "iOS: not built here." "Windows: no push." "Browser: not a scanner." The season's least glamorous code and its most trustworthy.
The runbook. docs/pocket.md, written in the same session as the code it describes — the only time anyone ever writes one.

🧠 Model pick, the season's rule: Opus wherever the question was about semantics — foreground versus background versus stopped, what "resumed" must mean for a socket, whether stale data is read-only, what not to fake; Sonnet wherever Essentials or a documented toolchain did the heavy lifting — geolocation, storage, CSS, signing, YAML. Same principle as the two seasons before, on a new axis: in a mobile app, the consequence of a cheap-model mistake is a notification that never arrives.

The three things the bench couldn't prove

Every part photographed what it claimed, and three claims could not be photographed. They belong together, so nobody has to hunt for them:

Windows toast notifications never displayed. Not in Part 5, not in Part 10, not from Part 11's published build. Registration succeeds, the OS setting says Enabled, Show() returns, and no banner appears. The cause is app identity — the unpackaged build has none — and the fix is MSIX packaging or an installer-made shortcut with an explicit AppUserModelID, neither of which this series demonstrates, because sideloading an MSIX means trusting a home-made certificate. The Windows app says "Allowed" and shows nothing. That's the honest state.
No on-device QR decode was photographed. The emulator never rendered its virtual-scene posters, so the scanner was only ever pointed at a virtual living room. The chain — the server's PNG, read by ZXing back to cliniclive://visit/CODE, through the parser — is proven by TicketQrTests, which runs in CI. Everything except the lens.
Google Maps crashed on the emulator. After the package-visibility fix the directions intent resolved and Maps launched — then died, the emulator's stale Maps build without a Play sign-in. What we control worked; what a real phone does next was not shown.

Windows: Allowed, nothing shown

The emulator's Maps

Two of the three, exactly as they happened. Left: the season's only full-screen Windows capture — taken with the app maximized so nothing else could be in frame — and the banner that isn't in it. Right: Maps, resolved and crashed. The third has no picture, which is rather the point.

Was Blazor Hybrid the right bet?

Part 1 made the case before any code existed: for a companion to an existing Blazor product, the screens would be the cheap part and the platform edges the whole cost, so sharing the screens would pay for itself. The retro gets to check it.

The screens were cheaper than cheap. Five pages written once; the Settings triplet above is the proof they never learned where they were. Season two's tokens carried straight over, dark mode included. The waiting-room page was forty lines because the live plumbing already existed. And the party trick paid off exactly where it mattered: a native camera page pushed over the WebView, because the WebView is just one page in a native app.

The edges cost what edges cost, and the table above is that bill: insets CSS can't see, a status bar the tokens can't reach, a cold start three and a half seconds slower with the SignalR client, a 33.8 MB APK and a 235 MB Windows folder, the AndroidX version dance, toasts that need an identity, iOS compiling but never built for want of a Mac. None of that is Blazor's fault — and, the honest point, none of it would have been avoided by going native. A Kotlin app meets package visibility and the stopped state too; a WinUI app meets the same identity rule. Native would have paid the same edge bill and rebuilt the screens, three times.

So: yes, for this app — a small team, an existing Blazor product, screens that are forms, cards and one big number. Where the bet goes the other way: an app whose product is the camera, or gesture-heavy motion, or platform idioms polished enough to sell a store listing. There the WebView is the wrong stage and shared screens the wrong savings. Know which app you have before you place it.

The tests postscript

The number that grew all season: 9 tests from season one, 13 after Part 3's API tests against a real Postgres, 15 after Part 6's push test with a fake sender, 20 after Part 7's haversine, 28 after Part 8's QR round-trip and parser — and 28 green through Parts 9, 10 and 11, which changed nothing the tests can see. Two of them caught the AI red-handed: the wrong "known distance" and the regex that let a banned letter back in. The harness built in season one is now what lets a phone, a desk and a browser share one set of rules without anyone re-checking them by hand. Three seasons in, the compounding return on those first nine tests is the least surprising and most useful fact in the trilogy.

✅ Checkpoint, the last one: you've now shipped a companion app, not a demo of one — shared screens on three hosts, nine capabilities answered honestly, a live queue, push to a closed phone, haptics proven by the kernel, a QR pipeline proven by a test, offline that tells the truth about its age, a signed build and CI. And you know exactly which three things it can't yet prove. Here's what's next: pick one screen of an app you own, put its native needs behind a capability interface, and run it in a second host. You'll meet your first edge within the hour — write it down.

Where next 🎉

Twelve parts, one companion app, $7.20. The whole three-season arc — every prompt, every tag, every honest screenshot — lives in the ClinicLive repo; the README's season-three table maps pocket-02 through pocket-11 to their parts, and docs/pocket.md takes you from a fresh clone to a signed APK.

If you arrived through the pocket door, the story starts two seasons earlier: From Prompt to Production, Part 1 builds ClinicLive from a spec to a VPS, and From Prompt to Polish, Part 1 makes it something people would want to use. The full catalog of everything on this site is on the series page.

And that's the trilogy complete. Season one proved AI can build software with you. Season two proved it can design with you, steered. This season proved it can reach the parts of a product that live on someone else's operating system — and that the steering matters more there, not less, because the mistakes are no longer in the code where a diff can show them. A prompt that says what not to fake. A bench that toggles airplane mode. A log that keeps the dead ends next to the wins. A skeptic reading the exit codes. The tools got the app onto the phone; the honesty is what makes it worth trusting there.

Thanks for coming all the way — three seasons, thirty-six parts, one clinic. If any of it helped you ship something, or you hit an edge this series didn't, the contact page is open and I'd genuinely like to hear about it. Now go put something of yours in someone's pocket. 📱

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

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:

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.