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

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)

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:

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

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.