Eight weeks is not a magic number. It is how long a small team can hold a single focus before scope starts expanding. This timeline comes from a real product we built — with what was done and what was deliberately postponed.
Week 0: the decision that shapes everything
Before any code: who is the single user who will pay first, and what is the single task they will pay for? Not «small businesses» but «an accounting firm serving ten entities that is drowning in invoices». The product is built for that person; the rest come later, or not at all.
Weeks 1–2: the core, without an interface
We build the thing that makes the product a product — the business logic — with an API and tests, and not a single screen. If the product proposes journal entries, the first two weeks go to proposing correct entries from a command line. The beautiful interface can wait; a wrong core is not fixed by design.
Weeks 3–4: the first end-to-end screen
One screen that completes the single task: sign in, input, result. No dashboard, no settings, no pricing page. The first user — the person defined in week 0 — is onboarded and actually uses it.
- What was built: authentication, the single task, a simple log
- What was deliberately postponed: billing, roles, reports, notifications, the mobile app
Weeks 5–6: billing and repair
Now — and not before — we add payment. Not because payment is hard, but because building billing before anyone uses the product means building a billing system for a product you do not yet know is used. And in the same week we fix what the first user broke — and they will break things.
Weeks 7–8: three paying users
The goal is not a hundred users; it is three who actually pay. Those three give you what a hundred free users never will: a real reason to pay, a real objection to the price, and one feature all of them ask for. That feature is week nine.
Why scope kills small products
A technical mistake is fixed in a day. Excess scope is fixed by a rebuild. Every «small» feature added before anyone pays doubles what must be maintained and slows the one feature that matters. The rule we hold: no feature before week 8 unless a paying user asked for it — or its absence stopped someone from paying.
A small product does not die because it is small. It dies because it tried to be big before it was useful.
In short
Eight weeks: two for the core, two for one screen, two for billing and repair, two for three paying users. And everything else — everything — waits until someone paying asks for it.
