I Built a Clinic Booking System with a Single Prompt. Here's What Actually Happened.
A complete Oslo clinic booking app — four-step patient flow, admin dashboard, Resend emails, SQLite database — scaffolded in one Claude Code session. Honest notes on what worked and where I had to push back.
The prompt was 847 words long. I know because I counted it afterwards, slightly embarrassed about it.
It was a Tuesday afternoon in Oslo. I'd been thinking about a gap that's common for small medical practices here: the distance between “we have a website” and “patients can actually book online.” Most clinics use expensive SaaS platforms with mediocre UX, or they're still taking bookings by phone. I wanted to see how close I could get to a complete, deployable booking system in a single Claude Code session.
So I wrote the prompt. I specified the tech stack — Next.js 14, TypeScript, Tailwind, Framer Motion, better-sqlite3, Resend — three Oslo clinic locations, six Norwegian doctors with different specialties, a four-step patient booking flow, an admin dashboard with password protection, pure-SVG charts, and HTML email notifications. Then I hit enter.
Four minutes later, I had 32 files.
That's still strange to type. Not 32 stubs. A working application with a real SQLite database pre-populated with dummy appointments, Framer Motion transitions between booking steps, SVG doctor avatars generated from initials, and HTML email templates. I ran npm run dev and it loaded on the first try.
Patient booking flow
The design decisions that translated
The step indicator was something I'd thought about before writing the prompt. A row of four circles connected by an animated progress bar — active step filled blue, completed steps showing a checkmark, future steps grayed out. The intent was to reduce patient uncertainty: always know where you are, always know how much is left. It came out exactly as I'd described. When I reviewed the code, I found a Framer Motion pathLength animation on the checkmark that I hadn't specified. Good call.
The doctor cards use generated SVG avatars: a circle coloured deterministically from the doctor's name, initials in white text. It's a small decision but a correct one. No placeholder images, no photo shoot needed, the UI looks complete. The calendar shows the next 14 weekdays in a scrollable row. Available slots are blue buttons. Booked slots are grayed out with a line-through. Unavailability is legible at a glance. These are obvious design choices in retrospect — but the point is they appeared correctly without me labelling them as “obvious.”
Where it surprised me
The admin dashboard. I'd asked for a bar chart and donut chart built in pure SVG — no Recharts, no D3, no external charting library — to keep the dependency footprint small. Both came back working. The donut chart calculates arc segments correctly, renders a legend, handles the case where one doctor has zero bookings. I would have reached for a library. Claude didn't.
The email confirmation template also came back cleaner than I expected. Table-based layout, inline styles, all the booking details in a properly formatted block. It renders correctly in Gmail.
Admin dashboard layout
Where I had to push back
Database initialization. The first version tried to open the SQLite connection at module import time, which breaks in Next.js because server modules can be initialized in contexts where native binaries aren't available. I had to be explicit: wrap the connection in a getDb() function called lazily inside each exported function, never at the module top level. One correction, one iteration, fixed. The mistake wasn't surprising — it requires understanding how Next.js evaluates server modules, which isn't obvious from the surface of the problem.
I also had to push on the email templates specifically. The first pass used <link> tags for web fonts, which email clients strip silently. Resend's documentation is worth reading before you generate email templates — knowing what constraints exist helps you specify around them. I asked for inline styles only, table-based layout, no external resources. That version renders correctly.
What this means in practice
Andrej Karpathy coined “vibe coding” in early 2025 to describe this mode of working: you describe at the level of intent, the AI implements, you stay in product-thinking mode rather than syntax mode. A GitHub study on AI-assisted development found developers completed tasks 55% faster on average. For scaffold-heavy work like this — routing, database schema, form state, email templates, chart rendering — I'd estimate higher. For subtle async state management or anything requiring real architectural judgment, much lower.
The honest version: this app took real thought. The prompt was 847 words long because the spec was precise. Vague prompts produce vague code, and vague code in a booking system means patients seeing wrong available slots or confirmation emails going to the wrong address. You still need to know what a good booking system looks like, which constraints actually matter (mobile-first, server-only database imports, email-safe HTML), and where the AI is likely to take shortcuts. The thinking doesn't disappear. The typing does.
A complete, deployable clinic booking system in one session. It's not magic. It's a very fast implementation of a precise specification.
What's the version of this in your industry — the tool that everyone knows would be useful, but nobody has built because it always seemed too small to justify the cost?