Scaffold your validated v1 with Claude Code (UK, 2026)

You did the hard part already.

You ran the smoke-test landing page, made the Mom Test calls, and pre-sold founding members before writing a line of code. Three people have paid in pounds for a product that does not exist yet. Now you have to build it.

This is where most UK indie hackers either freeze or sprint off in the wrong direction. The freeze comes from staring at an empty repo. The wrong-direction sprint comes from opening Claude Code and typing "build me a SaaS app" - which gets you a fast, confident, generic app that does not keep a single one of the promises you made on three sales calls.

There is a better first move, and it takes about half an hour before any code exists.

Turn one is not for code

The single biggest leverage point with a coding agent is the context you hand it before it starts. Claude Code in 2026 will happily scaffold an entire app in one session - the constraint is no longer typing speed, it is aim. An unaimed agent builds the wrong thing fast and you only notice three sessions later when you are trying to bolt your actual feature onto a structure that fights it.

So turn one is for two files and a plan.

PRD.md - what you are building

Write a one-page product requirements doc. Not a thesis - a page. It answers:

• What does the app do? One sentence a founding member would recognise.
• Who is it for? The exact person you interviewed, not "businesses."
• The three promises. What did your founding members actually pay for? These are non-negotiable v1 scope.
• Core flows. The two or three things a user must be able to do. Sign up, do the one valuable thing, see the result.
• Out of scope for v1. Write this list longer than you are comfortable with. Every line here is a weekend you save.

The validated idea is your spec. The PRD is just where you write it down in a form the agent can read.

CLAUDE.md - how this codebase wants to be worked

This is the file Claude Code reads at the start of every session. It is not the product spec - it is the operating manual:

• Tech stack and versions: Next.js, Supabase, Stripe, deployed on Vercel.
• Naming conventions and folder structure.
• Commands: how to run tests, how to deploy, how to seed the database.
• Available APIs and keys (names only - never secrets in the repo).
• UK rules: GBP currency, EN-UK spelling, how VAT is handled.
• Hard constraints: no secrets committed, no untyped any, whatever you care about.

If you have used Claude Code before, you have probably already met the CLAUDE.md as project rules pattern. This is the same idea applied from line one of a new repo. The payoff is that the agent stops re-deriving your conventions every session and stops quietly choosing its own.

Plan before code

With both files written, open Claude Code in plan mode and give it a prompt shaped like this:

Read PRD.md and CLAUDE.md. Propose a directory structure, the first five files to create, and three architectural decisions I need to make before you write any code. Do not write code yet.

Plan mode exists precisely for this moment. You will get a structure, a short build order, and a few genuine forks - which auth pattern, where the Stripe webhook lives, how multi-tenancy works if you need it. You decide those with your eyes open instead of discovering them by accident in week three. If plan mode is new to you, the plan mode walkthrough covers the mechanics.

Session one ships a skeleton, not a feature

Here is the goal for your first real coding session, and it is deliberately modest: an app that builds, runs, and is live on a Vercel URL. Every page can be a placeholder that just names the feature. That is success.

What "skeleton" means concretely:

1. Framework up. Next.js scaffolded, runs locally, one route renders.
2. Database and auth wired. Supabase connected, connection verified from a real query, auth provider configured (even if the login page is bare).
3. Folders match the PRD. The structure plan mode proposed, created and committed.
4. Continuous deployment connected. Push to main, Vercel builds, the URL goes live.

You are building the rails, not the train. The reason this is the right scope is psychological as much as technical: a deployable skeleton on day one means every session after this ships something a founding member can actually click. You never reach the demoralising week-three state of a half-built app that has never once run end to end.

Ask Claude Code to build the skeleton against the plan it just produced. Review the diff. Run it. Commit.

Why not just clone a boilerplate?

It is tempting. There are good Supabase-plus-Stripe starter kits, and cloning one saves an afternoon. But for a v1 you are about to hand to three paying founding members, that afternoon is the wrong thing to optimise.

A boilerplate ships with auth, billing, and a dozen patterns you did not choose. The first time production breaks - and it will - you are debugging a stranger's abstractions at 11pm with a founding member waiting. Scaffolding the skeleton yourself with Claude Code is genuinely an afternoon in 2026, not a week, and every file in the repo exists because you or the agent decided it should. The CLAUDE.md documents the why. When a bug lands, you can fix it because you understand the thing.

Use the agent to move fast. Do not use a stranger's repo to avoid learning your own codebase.

Deploy the empty thing on day one

This is the step people skip, and it is the one that saves launch day.

The gap between "works on my machine" and "works in production" is where weekend projects quietly die. You want to find that gap on day one, when it is a five-minute environment-variable fix, not on launch day when three founding members are waiting for a login link.

Deploying the empty skeleton immediately proves four things at once:

• Continuous deployment actually works.
• Environment variables are set correctly in the live environment, not just .env.local.
• The database connects from production, not just your laptop.
• You have a real URL.

That last one matters more than it sounds. A live URL that grows a little every day feels like shipping. A localhost app that never leaves your laptop feels like homework. Send the skeleton URL to a founding member with a one-line "building now, here is the shell" and you have turned a paid promise into a visible, moving thing.

What the "first five files" usually are

When plan mode proposes the first five files, you do not have to accept them blind. For a Next.js plus Supabase v1, a healthy first five tends to look like this, and it is worth knowing the shape so you can sanity-check the agent:

1. The CLAUDE.md (already written) and a PRD.md (already written) - these are the two the agent reads, not the two it writes, but they anchor everything below.
2. A Supabase client/server setup file - the single place the database connection is configured, so the rest of the app imports one client instead of each route inventing its own.
3. A root layout and one real route - the page that proves the framework renders and that you can navigate. This is where the skeleton becomes clickable.
4. A database schema or migration file - even if it only defines a profiles table linked to Supabase auth, having the schema in the repo from file one means the data model is version-controlled, not clicked together in a dashboard you will forget you changed.
5. An environment-variable template (.env.example) - the named keys the app needs, with no values, so future-you and the deploy environment both know what must be set. The real secrets live in Vercel and your local .env, never in the repo.

If plan mode proposes something wildly different - a dozen files, a complex state-management layer, an auth implementation from scratch - that is your signal to push back. Reply "this is too much for a v1 skeleton, propose the smallest set that builds, runs, and deploys." A good agent narrows happily. The skill you are practising here is not accepting the first plan; it is recognising when the plan is heavier than the job.

Keep the agent on the rails

One more habit that pays off from session one: after every meaningful change, have Claude Code run the build and the dev server, and you click the route. The reason is that an agent moving fast can drift - it adds a dependency that does not install cleanly, references a file it has not created yet, or assumes an environment variable that is not set. Catching that drift inside the same session, while the context is fresh, costs seconds. Catching it three sessions later costs an archaeology dig.

The CLAUDE.md is where you encode this: a line like "after any change that touches routing, data, or dependencies, run the build and confirm it passes before reporting done" turns a hope into a habit the agent follows. You are not micromanaging - you are setting the standard once and letting the agent hold itself to it.

The 30-minute setup, then go

To recap the first session end to end:

1. Write PRD.md (the product, the user, the three promises, out-of-scope). 15 minutes.
2. Write CLAUDE.md (stack, conventions, commands, UK rules, constraints). 15 minutes.
3. Plan mode: structure, first five files, three decisions. Make the decisions.
4. Build the skeleton against the plan. Review, run, commit.
5. Deploy to Vercel. Watch it go green. Send the URL to a founding member.

That is one afternoon. At the end of it you have a live, deployable, properly-aimed foundation that keeps the promises you sold - and tomorrow you build the first real feature into rails you understand.

Next in this build sequence: wiring Supabase auth and Stripe billing so your founding members can log in and pay in pounds.

---

Building your validated idea? IdeaStack publishes one deeply-researched, UK-specific business opportunity every week - real keyword volumes, competitor analysis, SERP landscape, and copy-paste builder prompts. Read this week's free report and find the next idea worth scaffolding.