Two hours to set up, and one principle underneath every choice: from hour zero you own everything. The code, the infrastructure, the database, the domain. Not a project inside someone's builder, not an export you'll have to rescue later — a repository on your machine and a server you hold the keys to.
That principle is not ideology. It is the difference between a product that can still be worked on next month and one that quietly becomes someone else's asset while you were busy shipping.
The stack
Four decisions. Make them now, write them down, do not revisit them today.
| Layer | Use | Why |
|---|
| Agent | Claude Code CLI | Runs in your terminal, on your repo, with your files |
| Framework | TanStack Start | One codebase, full stack — server routes and UI together |
| Styling | Tailwind CSS | No design system to invent, no CSS file to maintain |
| Infrastructure | Railway | App, Postgres, and the domain, bought and pointed in one place |
Everything on that list produces artefacts you keep. The repo is yours. The container spec is yours. The database is a real Postgres you can dump and move. The domain is registered to you.
There is a fifth tool — PostHog, for analytics — and it is deliberately not one of today's early decisions. You install it at hour twenty-one, in the ten minutes before you send the link, and its free tier means it costs you nothing to have. Lesson 8 covers it.
Claude Code, in your terminal
Claude Code runs where your code already lives. It reads the real repository, edits real files, runs your real dev server and tests, and commits with git — so the output of a day's work is a normal project history rather than a session inside a web app.
Two habits are worth forming in the first hour:
Write a CLAUDE.md before you write features. A short briefing file — how to run the app, which folders matter, the conventions you care about. Five minutes, and every session after it starts informed instead of guessing.
Plan before you build. Ask for the plan first, read it, correct it, then let it execute. Correcting a wrong plan costs a sentence; correcting a wrong implementation costs an hour you do not have.
Mix Opus and Sonnet — that's the budget
The single biggest lever on how far your usage stretches is not prompting technique. It is using the right model for the right kind of work.
Claude Opus 5 for thinking. The initial architecture. Cutting scope. The one genuinely hard problem in the spine. Debugging something that has already resisted two attempts. This is where reasoning quality changes the outcome, and where the day is won or lost.
Claude Sonnet 5 for volume. Building the routes. Wiring the forms. Styling the pages. Writing the copy. Fixing the obvious type error. This is most of the day by hours and by tokens, and it is work where the difference between models rarely shows up in the result.
Run the split deliberately — hard thinking on Opus, everything downstream of a decision on Sonnet — and a day of continuous, genuinely useful agent work sits comfortably inside a normal plan. Run everything on the heaviest model and you will spend the afternoon watching a usage limit instead of shipping.
The practical rhythm: Opus decides, Sonnet executes, Opus is brought back only when execution hits something that needs a real decision.
TanStack Start and Tailwind
TanStack Start gives you one project for both halves of the product — server routes, data loading, and UI in a single codebase with types flowing between them. On a one-day build the value is not the feature list, it is that there is no second service, no separate API repo, no deploy step you forgot about.
Tailwind removes the styling decision entirely. You are not writing CSS files or naming things; you are applying a spacing and type scale that someone already got right. Lesson 6 leans on this heavily.
Railway for all of it
Buy the domain on Railway, deploy the app on Railway, run the database on Railway. One dashboard, one bill, and — this matters at hour twenty-two — one place to look when something is wrong.
The order to do it in:
- Create the repo and push the starter template.
- Deploy it to Railway. An empty page live on a real URL.
- Buy the domain and point it at the deployment.
- Add the Postgres instance now, even if today's product may not need it.
Fifteen minutes, and the entire deployment class of problems is behind you rather than ahead of you at hour twenty-three when you are tired and the build is failing over an environment variable.
Why not Lovable, or anything like it
You do not need Lovable, Bolt, v0, or any of the prompt-a-website products, and on this day they cost you more than they save.
They are genuinely fast for the first twenty minutes — a page appears, it looks plausible, it feels like progress. Then you need something the builder does not do: a specific database query, a webhook, a library it has never heard of, a fix in a file it will not show you. Now you are fighting the tool instead of the problem, and your escape hatch is an export that drops you into an unfamiliar codebase with none of the context you would have had if you had written it.
The trade is worse than it looks. You are renting the twenty minutes and paying with the ownership. A terminal agent working on your own repository is nearly as fast at the start and does not have a ceiling in the middle.
None of this is a rule about serious versus unserious tools. It is about which end of the day you want to be comfortable at.
What to skip entirely
Today you do not set up: a testing framework, your own component library, a design system, linting beyond the default, a monorepo, a staging environment, Docker, or CI beyond what Railway does for free.
None of that is wrong in general. All of it is wrong now. Infrastructure pays off across months, and you have hours.
Before you move on
You should now have: a live URL on your own domain, a repo with one commit, a database waiting, CLAUDE.md written, and four locked decisions. That is the correct state at hour six — and every one of those things belongs to you.