A first version that answers one question
An MVP is not a smaller product. It is an instrument for answering one question you cannot answer any other way — and the hardest part is deciding which question that is, because everything else in scope follows from it.
Deciding what the release has to prove
Most first releases fail on scope rather than execution. A team builds the product it eventually wants, at a quality it cannot yet justify, and runs out of runway before learning anything.
The useful discipline is naming the question first. Will people pay for this? Can we acquire users at a viable cost? Does the workflow survive contact with a real operator? Each of those implies a different build, and some imply barely any build at all.
Which decisions are still expensive to reverse
'Minimum' applies to scope, not to the decisions that are structural. A few choices cost roughly the same to make properly now and are painful to unwind later: how tenants and their data are separated, how identity and permissions work, and how money moves if the product takes payments.
Getting those right in a first release is not gold-plating. It is the difference between a version two that adds features and a version two that starts again.
What ships with a first release
A working application deployed to an environment you control, the repository and its history, and enough documentation for another engineer to run it. Analytics wired to the question the release exists to answer, so the result is measurable rather than anecdotal.
We have taken products from concept through first release and beyond — TocoPick and OptionTeller both began as first versions and grew from there.
Founders validating a product before committing to a full build
Teams inside a larger company testing a new line without the main platform's constraints
Anyone whose next funding conversation depends on showing something working
Products where the requirement is already well understood and the real need is capacity — a dedicated team fits better
Regulated builds where the compliance surface cannot be deferred; the minimum viable version is not much smaller than the full one
Teams who want a cheap version of the finished product. That is not what this is, and framing it that way reliably produces both
We do not publish rates, because scope decides them
A figure quoted before scope is understood is not a commitment either side can rely on. These are the things that actually move it.
How settled the scope is
A defined feature set costs less than one still being decided. Discovery reduces this before it becomes a build cost.
Number of surfaces
Web alone is one build. Web plus iOS plus Android is three, whatever the shared codebase.
Integrations
Payments, identity and third-party data each add real work, and each has failure cases that need designing for.
Design starting point
An existing brand and design system shortens this; starting from nothing does not.
NDA first, contract on frozen scope
We sign a mutual NDA before the first detailed conversation, not after — you should be able to describe what you are building without qualifying it.
The contract follows requirement freeze rather than preceding it. Once scope is agreed and written down, it is what the agreement is drawn against, which is what makes a fixed commitment meaningful in the first place.
What buyers usually ask
Something not covered here?
Ask directly — we would rather answer a specific question than publish a general one.
Contact us01
How long does an MVP take?
It depends almost entirely on surface count and integrations rather than on ambition. We give a range after scoping rather than a number before it, because a figure quoted against an unclear scope is not a commitment either side can rely on.02
Do you help decide what goes in it?
Yes — that is discovery, and it is the part with the highest return. The cheapest place to be wrong about a product is before it is built.03
What if we need to change direction mid-build?
Expected, and the reason we work in sprints. Direction changes are cheap; a scope that was never frozen is not.04
Will we need to rebuild it later?
Features get replaced; foundations should not. We make the structural decisions properly even in a first release, which is what keeps version two an extension.05
Who owns the code?
You do, from the first commit.
Industries
Also relevant
Scope your first release
Tell us what you are trying to prove and who it is for. We will come back with a scope, a realistic first milestone, and what we would cut.
- NDA before we talk
- Reply within one business day
- No obligation