Six decisions before your first prompt, and why each one is there

Nobody wants to spend an afternoon on setup. The pull is to open a chat and start describing the thing, and for a prototype that is the right instinct — the first week has its own post and most of the advice there is go faster.

This is the other post. It is for the moment you decide the thing will still exist next month, and it is six decisions. Each takes minutes. Each closes off a specific way week two goes wrong, and the reason to make them together is that all six are cheap now and expensive later.

None of them is about which model is best.

1. GitHub, which is an undo button you can talk to

If you have never used it, ignore how it is usually described. GitHub is not a social network for programmers and you are not there to read anyone’s code. It is a save system with a history, hosted somewhere that is not your laptop.

Five words cover almost everything you need:

• Repository — your project folder, plus every version it has ever been.
• Commit — a save point with a note attached. “Login screen works” is a commit.
• Branch — a copy of the project where you can break things without breaking the original.
• Push / pull — sync between the copy on your machine and the copy on GitHub.
• Pull request — “here is a change, look at it before it goes in.” You will not need this alone; you will need it the day somebody else touches the project.

Here is why a vibe coder specifically cares. At some point — not maybe — a session will rewrite something that already worked. It will refactor a file you liked, or delete a function it decided was unused, or fix one bug by introducing two. Without commits, that work is gone and your only recovery is describing it again from memory. With commits, recovery is one sentence.

Which brings up the part nobody tells beginners: you do not have to learn Git. You have to learn three sentences to say to your agent.

• Commit this with a clear message.
• What has changed since the last commit?
• Undo everything since the last commit.

That is the whole interface for the first month. The agent runs the commands.

Set it up like this and stop thinking about it: create the account, make the repository private by default, and before anything else make sure .env is in .gitignore. That single line is what stops your API keys from being published the first time you push. Keys leak from beginner repositories constantly, and they are scraped within minutes.

Then one habit, which is the highest-leverage thing in this entire post: when something works, commit it. Not at the end of the day. At the moment it works.

That is enough to start with. The rest of it — reading a diff without reading code, the four different kinds of undo and when each applies, what to do the day you commit an API key — is the full guide.

2. One model, and it matters less than you think

Claude Code, Codex, or an open-weights model you run yourself. The honest framing: this is the one decision you can reverse for free. The repository is portable, your prompts are portable, and nothing you build is locked to the tool that wrote it.

What actually separates them is not benchmark scores, it is whether the tool lives in your project:

The recommendation: pick one paid agentic tool and stay on it for a month. Not because the others are worse, but because the skill you are building is knowing what to ask for and how to tell when the answer is wrong, and that skill transfers slowly while you are still switching tools every week.

On open source, being straight: it is real, it is cheaper, it is private, and it is the wrong first move. You will spend your first week on setup instead of on the thing you wanted to build, and long agentic tasks — many files, many steps, hold the plan the whole way — are exactly where the gap is still widest. Come back to it in month two, when you know what you are comparing.

And whichever you pick, the leverage is not in the model. It is in what the model can see about your project, which is decisions 4, 5 and 6.

3. One host, and one account if you can manage it

You will need somewhere to put it. The two obvious answers are Cloudflare and Vercel, and the deciding question is not performance.

It is how many accounts you want to hold.

Cloudflare is the all-in-one: hosting, a database (D1), file storage (R2), key-value, the domain itself, DNS, email routing — one login, one bill, one place where things are wrong when they are wrong. For someone starting out, that consolidation is worth more than any individual feature. The price is a runtime that is not quite Node, so a handful of npm packages will not run there, and you find out at deploy rather than at install.

Vercel gives you the smoothest deploy in existence if you are on Next.js. The trade is that the data pieces come from marketplace partners, so the database is somebody else’s dashboard, storage is another, and you will be reconnecting three services on a Sunday evening trying to remember which one has the failing credential.

Pick Cloudflare unless you have a specific reason to be on Next.js.

And buy the domain on day one, from the same provider. It costs about ten euros, it takes four minutes, and it changes how you treat the project. A thing with a domain is a thing that exists.

4. A stack — chosen by you, written down

The temptation is to leave this to the model. Do not, and the reason is not that its choice would be bad.

It is that the model chooses per conversation. Monday’s session picks Next.js. Wednesday’s session, with no memory of Monday, picks Vite and React Router. Friday’s adds a component library that duplicates the one you already have. Nothing errors when this happens — you just end up with a project that is three projects wearing a trenchcoat, and every future session has to guess which convention it is in.

So: React + Tailwind, and tell the model to use shadcn/ui.

Why that specific combination, when plenty of others are perfectly good:

• It is the best-documented combination in any model’s training data. You are choosing the region of the map where the model is at its most accurate and least inventive, and that is worth more than any technical advantage on day one.
• Tailwind keeps styling in the markup, so when you say “make this card tighter”, the agent changes one line in the file you are looking at instead of hunting a stylesheet.
• shadcn components are copied into your repository, not installed as a dependency. This is the underrated part. When you ask for a change to a button, the agent edits your button. With a traditional component library, it has to fight the library’s API, and it will usually lose by wrapping it in three layers of nonsense.

One exception, and it is a common one. If what you are building is mostly content — a site, a landing page, a blog, a documentation set, with a small admin area attached — use Astro instead. It ships almost no JavaScript by default, the pages are fast without you doing anything, and it scales into a real application when you need it. This site is Astro.

Skills: how you stop repeating yourself

A skill is a folder with a SKILL.md file in it that your agent reads only when it is relevant. That last part is the whole point: it is instructions that are available without being in the way.

The anatomy is small. A file at .claude/skills/<name>/SKILL.md, starting with:

---
name: my-design-system
description: Use when building or restyling any UI in this project —
  colours, typography, spacing, component patterns.
---

Everything the agent should know, in plain markdown.

The description is the important line, because it is what the agent matches against to decide whether to load the skill at all. Vague description, skill never fires.

Two places to put them: .claude/skills/ inside your project, which means it is committed to GitHub and it is still there tomorrow and on your other machine, or ~/.claude/skills/, for things you want in every project you touch. Prefer the project one — a skill that describes this product belongs with this product.

To install one somebody gave you: drop the folder in, start a new session, and ask what skills do you have available. If it does not list, the description is the first thing to check.

That is the shape of it. Why the description is the only part that always loads, what belongs in a skill versus AGENTS.md, and the fastest way to write your first one — the full guide.

(Skills are a Claude Code feature. If you went with Codex, the equivalent lever is the AGENTS.md file described in the bonus section — same idea, less selective loading.)

The design one is worth doing on day one. If you have an idea but no brand, no colours and no visual opinion yet, go to startpow.com, pick what you like, export, and choose the skill download. Drop it in .claude/skills/. From that moment every screen the agent builds arrives in your colours, with your type and your spacing, without you describing them again — which is the difference between a product and a demo, and it costs about ten minutes.

5. Something that remembers, so tomorrow is not a rebuild

Here is the failure this decision is about, and it is worth being precise because the popular version is wrong.

The model is not malicious. It is agreeable and fast, in places where being wrong is expensive. The database does not get dropped by a rogue AI; it gets dropped because a migration was broken, dropping the table was the shortest path to a passing test, and nobody was asked. Auth does not get rewritten in an act of sabotage; it gets rewritten because a test was failing and the auth check was what was failing it.

Two layers of defence, and the first one is free:

The habits. A development database that is not the production database. Production credentials the agent never holds. A commit before you start anything. And the instruction most people never give — what it must not touch. Models are agreeable; they will happily do a helpful thing you did not want.

The tooling. This is what CommitCycle is: work starts as a task with a declared scope, the agent gets access bound to that one task and one branch and it expires on its own, the paths that would actually hurt carry an owner who has to say yes, and every task closes with a record of what was declared against what was touched.

Now the honest limit, which is also the most important sentence here: it does not remove the possibility. The final responsibility is always the person who approves what the agent asks. The agent executes; you consent. What the tooling removes is the class of accident where nobody could have said no, because nobody was asked — and that class is most of them.

If you want it: /plugin install commitcycle@commitcycle in Claude Code, or npm i -g commitcycle for the CLI. The hosted board is invitation-only while this is small.

6. Now what? Start with the shape, not the screen

You have the six pieces. The instinct is to prompt build me the homepage, and it is the wrong first move — not because the homepage is unimportant, but because it is a consequence of decisions you have not made yet.

The first useful question is: does this need accounts? Almost everything sorts into four surfaces from there.

If the honest answer is “mostly public front, small admin”, build it in Astro and do not add an authentication system you will maintain for one user. If it is “mostly product”, the auth and the data model are the first thing, because everything else hangs from them.

The prompts

First, the one that writes no code. This is the highest-value prompt in the whole process and it is the one most people skip:

I want to build: [describe it in three or four sentences, including who
it is for and what they pay for, if anything].

Do not write any code yet. Interview me — ask me the questions you need
answered to plan this properly, one batch at a time.

When you have enough, give me back:
1. The screens, grouped into public / auth / product / admin
2. The data model, as a list of entities and how they relate
3. Any third-party service this needs and why
4. What you would build first, and what you would deliberately leave
   until later

You are making the model produce a question, and reviewing a question is far cheaper than reviewing three hundred lines of an answer built on an assumption you never saw.

Second, the foundation. Deploy the empty thing on day one — “getting it live” should never become its own project later:

Set up the project skeleton:
- [Astro | React + Vite], TypeScript, Tailwind, shadcn/ui
- Deploy target: Cloudflare
- A Git repository with a first commit, pushed to GitHub

Get an empty page deployed and give me the live URL before adding
any features.

Then write AGENTS.md at the root recording: the stack and the versions,
the folder layout, the naming conventions, the commands to run and
build, and anything you should never do in this project.

Do not add authentication, a database or any dependency beyond the
above yet.

Third, the surfaces that need a system behind them:

Build registration and login: sign up, log in, log out, password
reset, email verification.

Use [the auth provider you picked] rather than rolling it yourself.
Screens use our existing components — do not introduce a second
component library.

Also give me the smallest admin page that lists users, because I
need to be able to see whether this works.

Do NOT touch: payments, the marketing pages, anything under [path].
If you hit a decision I have not made — pricing, session length, what
happens to unverified accounts after a week — stop and ask instead of
choosing.

Notice the two lines that almost nobody writes: what it must not touch, and stop and ask instead of choosing. Those two lines prevent more rework than any amount of prompt-engineering finesse.

Fourth, once it works, make it yours: install the design skill and ask for one screen to be restyled with it. Check that one. Then let it run at the rest.

7. User stories, which is where this gets real

If you can narrate what a person does, you can build it. Take the user’s own sentence:

Someone sees an ad, lands on the site, creates an account, subscribes to a plan, pays by card, and their subscription unlocks.

Read it again slowly, because that one sentence is a specification. It contains:

• A landing page that the ad points at, which is not the homepage
• Registration, and therefore verification, and therefore email that actually arrives
• Probably onboarding, because a new account with nothing in it is where people leave
• A payment provider — Stripe, in practice — and a checkout
• A webhook, because the payment succeeds on Stripe’s servers and your app has to find out
• Entitlement: some state that says this account is now a subscriber
• Feature gating driven by that state, in every place it matters
• The failure path: card declined, payment succeeded but the webhook did not arrive, subscription cancelled mid-month
• An admin view, so that when someone emails you saying they paid and nothing unlocked, you can look

One sentence, nine work items, and the last three are the ones that get discovered in production by a customer if nobody wrote them down.

This is also work the model does well — hand it the story and ask what it implies, and it will produce a list very like the one above. What it cannot do is remember the list next Tuesday. That is what a board is for: each item becomes a task with a scope, a task becomes a branch, and the branch closes with a record of what it actually changed.

This sounds boring. It is, a bit. And in the interest of not overselling: three prompts genuinely can give you something that runs and looks good, and the hit of watching it work is real and worth having. Go and have it.

But the thing that is still standing in month three, that you can hand to somebody else, that you can change without holding your breath — that one was built by somebody who wrote down what it was supposed to do. Consistency is unglamorous and it is the entire difference.

Bonus track

Small things, in rough order of how much regret they prevent:

• AGENTS.md at the root of the repository. The single highest-return file you will write. Stack, conventions, commands, and the list of things never to do. Every agentic tool reads it. Ours generates one per task and clears it at hand-in, but a hand-written one is already most of the value.
• Two databases from the very start. Development and production, never the same credentials, and the agent only ever holds the development one. This is the specific defence against the specific disaster.
• Secrets never in the repository. .env in .gitignore, real values in your host’s secret store. Rotate anything that ever got committed — deleting the file does not remove it from the history.
• Preview deploys per branch. Both Cloudflare and Vercel give you a URL per branch free. Seeing the change on a real URL before it is live is worth more than any amount of local testing.
• Let the agent see what it built. Screenshots, or a browser tool it can drive. An agent building UI without ever looking at it is working blind, and it shows.
• Error tracking, plus exactly one analytics number you actually look at. Anything more than one and you will look at none of them.
• Terms and a privacy policy before you take a card. Stripe will ask for a working site with them before it activates the account, and finding that out on launch day is a bad day.
• Know your restore, not just your backup. An untested backup is a belief, not a backup.
• One decisions file. Three lines per decision: what, why, what you rejected. Six weeks later it is the only thing standing between you and re-litigating everything with a model that was not there.
• Expect the model to cost more than the hosting. That ratio is correct and it is not a sign you are doing it wrong.

The whole setup above is an afternoon. What it buys is that the second week is a continuation rather than an archaeology project — and if you want the habits that go on top of it, that is the first-week post.