How We Scope an MVP in 8 Weeks

Most MVPs don't fail because the code was bad. They fail because the scope was never agreed in the first place. Here's the shape of the process we actually use.

Week 1 — decide what not to build

The first week is subtraction. We list every feature anyone has mentioned, then cut until what remains can be demonstrated to a stranger in ninety seconds.

• One user, one job, one path through the product
• Anything a spreadsheet can do for now, a spreadsheet does for now
• Auth, billing and admin get the dullest possible implementation

If the demo needs a sentence of explanation before it makes sense, the scope is still too wide.

Weeks 2–7 — build in two-week slices

Every fortnight ends with something clickable on a real URL — not a status update. You can see the exact stack we use on the services page.

1. Slice 1 — the core loop, ugly but working end to end
2. Slice 2 — the second-most-important job, plus real data
3. Slice 3 — polish, edge cases, and the bits that embarrass us

What 'done' means

Done means deployed. A feature living on a branch is inventory, not progress — so every slice ends with a git push that reaches production.

# what a slice ends with
npm run build
git push origin master   # deploys automatically

Week 8 — hand over, don't hand off

You get the repo, the deployment, the docs and a walkthrough. No vendor lock-in and no dependency on us being available at 2am.

Thinking about a build? Tell us what you're working on — the first 30 minutes are free.