From Idea to Live Web App — Claude, Claude Design, then Claude Code

This was the highest-leverage part, and the one that's tempting to skip. Before any design or code, I used Claude as a thinking partner to get the idea sharp: what is this, who is it for, what are the pages, what's the data behind them, and what makes it worth existing. Treat it like a sharp collaborator — bring your messy notes, then push back on the first answers until it's genuinely clear.

I want to think through a product idea with you before I design or build anything. Here's my rough concept and notes: [paste everything].

Help me get it sharp:
1. In one sentence, what is this and who is it really for?
2. What are the core pages/screens, and what is each one's single job?
3. What's the underlying data model — the objects and their fields?
4. What's in scope for v1 vs. explicitly not?
5. Push back: what's unclear, over-scoped, or trying to do too much?

Ask me questions before answering. I want to leave this with a spec I could hand to a designer.

You'll know you're done when you could explain the product in a sentence and list its pages and data without hesitating.

Take the sharpened concept — the positioning, the pages, the data, and real copy (not Lorem Ipsum) — into Claude Design and let it produce an actual interactive prototype and design system: colors, type, spacing, components, all the screens. Then iterate by talking: "more restrained," "make this section feel like a story, not a form," "tighten the hierarchy." Stop when it looks like you, not a template.

The output of this stage is your spec for the build — a design that already answers the layout, copy, and interaction questions, so the code stage is about faithfully rebuilding, not inventing.

Give Claude Code the design as the source of truth and ask for a plan before any code — stack, structure, data model, and the risky parts — so you build in the right order.

Here's my design handoff / prototype [paste or attach files]. I want to rebuild it as a real production web app.

Before writing code:
1. Propose a stack and project structure.
2. Restate the data model and the routes you see.
3. List what has to be a real backend vs. what can be static.
4. Call out the riskiest/most ambiguous parts and ask me about them.

Then we'll build it in that order, starting with the data model.

Have Claude Code stand up the project and the data model before the pretty parts — everything downstream depends on the shape of your data. Keep editable content (copy, entries) in files or a simple data layer so you can change words without touching components.

The trick that made deployment painless: don't wire the database in directly. Have Claude Code define a small storage interface with two implementations — a local file/in-memory one for development, and the real database for production — picked automatically based on whether production credentials are set.

Add persistence behind a single interface (a Store) so I can swap implementations without touching the app:

- A local dev implementation (file or in-memory) so the app runs with zero setup.
- A production implementation backed by Supabase (Postgres).
- Select automatically: use Supabase when its env vars are present, else the local store.

Then write the SQL schema for the tables, and keep all secret keys server-side only.

The payoff: the whole app runs locally with no accounts, and going live is just adding environment variables.

For an admin area or signups: Supabase Auth for login, Resend for email. Two specifics that save an hour:

• For admin login, use a typed email code, not a magic link — email scanners "click" links to preview them and burn the one-time token (you'll see otp_expired). A code you type can't be pre-clicked.
• Point Supabase's own auth emails at Resend via custom SMTP, so you send from your domain and skip the built-in email rate limits.

Publish the repo to GitHub (GitHub Desktop is the no-friction way), then import it into Vercel, add your environment variables, and deploy. Vercel auto-deploys on every future push, so shipping a change becomes "commit and push."

In Vercel, add your domain, then create the DNS records it shows you at your registrar (an apex A + www CNAME, or switch nameservers to Vercel's). Delete any leftover "parking" records so they don't fight the new ones. Wait for the certificate, and you're live on your own URL.

The first deploy rarely works, and that's fine — the errors are the workflow. Paste each one back to Claude Code and fix it. The recurring lesson: make the build resilient (never let a live-data read crash a static build) and read errors literally — half of mine were a missing https:// or a variable that needed a redeploy.