ServicesMVP
The smallest versionthat proves it
One flow · end to end · in front of users
The smallest version that proves the idea, built so version two is not a rewrite.
Best whenYou have an idea and a date, and need something real in front of users.
- Scope
- Cut with you, in writing
- Shipped
- A working URL weekly
- Measured
- Analytics from day one
- Handover
- Repo, accounts, next steps
Four steps
An MVP fails two ways: it ships so thin it proves nothing, or so wide it never ships. Both are scope problems, so scope is the part we do in the open with you rather than behind a proposal.
01
Find the one flow
Not the feature list — the single path a user takes that, if it works, means the idea is worth building. Everything else is version two by definition, and gets written down as such.
02
Cut it in the room
We go through what is in and what is out with you, and you watch the cuts happen. A scope agreed in a call is a scope nobody can check in week four.
03
Build it to survive
Typed, deployed, with real auth and a real database. Fast to build is not the same as disposable — version two should be able to sit on this rather than replace it.
04
Measure, then decide
Analytics on the flow from the first release, so the next decision comes from what users did rather than what the room thought they would do.
What lands in your accounts
You leave with a product that works and the evidence to decide what happens next. The accounts are yours from the first deploy, so a change of mind about who builds version two costs nothing.
- One flow, built end to end and actually working
- Scope cut in the open, with you in the room
- A foundation the next features can sit on
- Analytics from the first release
PricingPriced from the written scope — one figure, agreed before code. No hourly billing, no change-request desk.
What lands when
Not a promise of six weeks — that number is set in your written scope, against your flow. It is the shape most MVPs take, and it is here so you can see where the cut lines fall before you agree to one.
Week 1
The one flow, drawn and cut. What is in version one, what is explicitly not, and which screen proves the idea. Agreed in writing before anyone opens an editor.
Weeks 2-3
That flow built end to end and deployed. Real data, real auth, a URL you can open — not a prototype that only works on the demo path.
Weeks 4-5
The edges that decide whether a real user finishes: the empty first run, the error that loses work, the form on a phone.
Week 6
Analytics on the flow, the repo and accounts in your name, and a written list of what version two should be — ordered by what you learned, not by what was left over.
Not a promiseA flow with payments or an integration adds weeks and we say so before you sign, not at week five.
Next step
Tell us what
you need built
Send the idea in whatever shape it is in — a document, a sketch, or two sentences. You get a written scope and a fixed figure back before anything is committed to.