Build version one

Version one does exactly what your pilots paid for, and nothing else. Write that in one sentence. If the sentence needs an 'and', you have two products.

Then write the kill list: every feature you can already imagine and are choosing not to build. Settings pages, admin dashboards, team permissions, mobile apps, integrations nobody asked for. Writing them down is what stops them creeping back in at week three, because the list makes the decision visible rather than forgotten.

Keep the kill list where you can see it. Every time someone asks for something, it goes on the list rather than into the build.

Pick the stack you can move fastest in that will not need a rewrite when you have ten times the usage. In practice that means a managed database, a hosted app framework, a payment provider you do not have to certify, and boring choices everywhere else.

The two mistakes are opposite and equally expensive: assembling a distributed architecture for a product with four users, or building on something so limited that the first real customer breaks it.

Write down your choices and the one thing that would force each of them to change. If you cannot name the breaking point, you have not thought about it yet.

Agents are good at the parts that are well specified and conventional: forms, CRUD, layout, tests, migrations, glue. They are unreliable at the parts where being wrong is expensive: access rules, money handling, data models you will live with, and anything involving other people's private data.

So brief them like contractors. Give the goal, the constraints, the file boundaries and the definition of done. Ask for small changes you can read in one sitting. Then read them.

Three things you review yourself, every time: who can read and write each row of data, what happens when a payment half-succeeds, and whether the data model still makes sense when you have a hundred customers instead of two.

Four things cannot be faked, because retrofitting them is painful and because your first customers are real people with real money.

Sign-in that you did not invent yourself. Payments that actually move money. A data model you have thought about for more than an hour. And a way to see what users do: events, errors, and a place those land where you will actually look.

Everything else can be manual. Onboarding by hand, support over WhatsApp, reporting exported by you on a Friday. Manual is fine. Fake is not.

Ship to a real URL, with real payments, to a real customer, while it still feels early. The gap between a private demo and a paying user is where all the information is.

Set the date now and treat it as fixed. Anything not ready on that date goes onto the kill list rather than moving the date. The first week live will teach you more than the previous three combined, and most of what you learn will be about the parts you would never have prioritised.