Day 0: setting up an AI project from scratch

Imagine you’re building a house. Before anyone lays the first brick, you pour the foundations. Boring? Maybe. But they decide whether the walls will one day crack.

With an app built with AI it’s exactly the same. Day 0 is that moment before the first line of code, when you make a few simple, deliberate decisions. You don’t need to know how to program. You just need to know what’s worth talking through with the assistant at the start.

Why this project at all

First the simplest thing, and the one most often skipped: why you’re doing it.

One sentence. Who the app is for, what problem it solves, what the user gains from it. Sounds trivial, and it saves you from a hundred small mistakes later — because the AI, when it knows the goal, makes better decisions for you.

While you’re at it, it’s worth talking through a few things that are hard to bolt on later:

How many languages the app should work in. One? Polish and English? Adding languages at the end isn’t a fix, it’s rewriting half the project — because every label (“Log in”, “Cart”, error messages) then has to be pulled out of the screens and wired to translations (so-called internationalization, “i18n” for short).
Whether and how you earn from it. Free, subscription, one-off payment? Payments bolted on after the fact are pain and moving data around.
How it should look and “feel” — serious and businesslike, or light and friendly.

You don’t have to know all the answers. If you don’t know something, say so outright — let the AI propose a sensible default and clearly mark that it’s an assumption, not your decision.

Where we keep the rules

Another foundation: a place for the rules of the game.

It’s one file (usually called CLAUDE.md), which is like the project’s constitution. In it you write down how things get run and what the assistant must stick to. That way you don’t have to explain the same thing again in every conversation — the AI reads it at every start. (How Claude loads such a file from the project’s memory is described in the Claude Code documentation.)

Here you also write your “sacred things” — rules that must never be broken. For example: never deploy changes to the live site without my explicit approval. Those are your red lines, written once, for good.

A copy you can return to

The most important safety rule, in plain language: always have a point of return.

Before the AI changes anything in important data, there must be a copy you can Rollback — Reverting a change to the previous, working state — “Ctrl+Z” for a deployment. When a new version breaks production, a rollback restores the previous one in seconds instead of fixing in a panic. to. Like a spare key to your flat — you keep it not because you plan to lock yourself out, but so that locking yourself out isn’t a disaster.

That’s why on Day 0 you decide: where backups land and that they’re made regularly, as soon as real users appear.

What is “sacred”

Finally, one boundary worth setting right away: production and user data are untouchable.

“Production” is simply the version of the app that real customers see. You change it only deliberately, on your explicit “deploy” — never “while we’re at it”. Same with people’s data: you change it with a copy up your sleeve and full attention.

That’s not an exaggeration. It’s the difference between a calm evening and panic at midnight.

The Day 0 checklist in plain words

Why — one sentence: who it’s for and what problem it solves.
Languages and money — how many languages, whether and how you earn (decide now, not later).
Rules of the game — one file with the rules the AI must stick to.
Sacred things — write down what must not be touched without your approval.
Backups — where they are and that they’re made automatically.
First move — walk through these points with the assistant one by one.

In short

Day 0 is the foundations. A few decisions before the code save you a mountain of fixes later.
Write down the goal, languages, money and sacred things — the stuff you can’t see in the code, but which changes everything.
Always have a copy and protect production — live changes only deliberately, on your explicit “yes”.