Built to answer a question, not to impress a demo audience
MVP Development
Most MVPs fail at the definition, not the build: teams ship a smaller version of the whole product instead of a sharp test of one belief. This practice starts from the hypothesis and builds only what is needed to get an honest answer, whether you are validating an idea, correcting a pivot, or proving a claim to investors.
How an MVP gets scoped here
From a stated hypothesis to a build that actually tests it.
90 secSample frame · video pending01Before you write a spec
The MVP question is never how much to build.
It is what you need to learn. Four tests separate a real MVP from a smaller version of the finished product.
Can you state the hypothesis in one sentence?
If not, the build cannot be scoped correctly, because nobody agrees on what it needs to prove.
What would prove the hypothesis wrong?
An MVP that cannot fail is not testing anything. Define the losing outcome before writing a line of code.
Is the metric instrumented before launch?
Deciding how to measure success after users arrive means the data will not answer the question you actually asked.
Would a fake front end answer it faster?
Some hypotheses are cheaper to test with a landing page and a manual process than with real software. Ask before building.
| Smaller product | Real MVP | |
|---|---|---|
| Scope driven by | Feature wishlist, trimmed | A single stated hypothesis |
| Success measured by | Whether it shipped | Whether the hypothesis was confirmed |
| Failure mode | Slow, expensive validation | Fast, cheap validation |
| What ships next | More features from the wishlist | Whatever the data actually supports |
02Agreed before the first sprint
The ledger that keeps scope honest
MVP engagements drift when scope creeps under pressure to look finished. This ledger fixes what you bring, what we build, what comes back, and what stays yours regardless.
- Your side
You bring
- The problem you believe exists
- Who you believe has it
- Any research or interviews already done
- Our side
We build
- The smallest version that tests the real hypothesis
- Instrumentation that measures whether it worked
- A build scoped to weeks, not quarters
- Your side
You receive
- A working product real users can try
- Usage data that confirms or kills the hypothesis
- A codebase built to extend, not to discard
Never leaves you
- The decision to pivot, persist or stop
- All intellectual property from day one
- Ownership of every user relationship formed
Where the line sitsWe build only enough to get an honest answer. The temptation to add features before the hypothesis is proven is the most common way MVPs become expensive failures.
03Weeks, not quarters
Four stages, each closing on evidence
An MVP that takes six months to validate a hypothesis has failed at the one job it had. This system compresses the loop and closes every stage with something you can act on.
Frame the bet precisely
The hypothesis, the losing outcome and the metric are written down together, so the whole team is testing the same thing.
A hypothesis nobody can misreadCut to the sharpest version
Every feature is tested against one question: does removing this change whether the hypothesis gets a fair test. Most things fail that test.
The smallest build that could workShip and measure
The build reaches real users with the metric already live, so the first data point is meaningful rather than a guess about what to track.
Real users, instrumented from day oneRead the result honestly
The data says persist, pivot or stop. This stage is designed to make that call defensible, whichever way it goes.
A decision, not a vibe
04What actually moves the number
Four drivers, priced from the hypothesis
MVP pricing follows the sharpness of the test, not a template. These four factors change scope more than anything else.
Hypothesis complexity
A single-workflow test costs less than a multi-sided marketplace hypothesis, which needs both supply and demand represented to mean anything.
Integration requirements
Payments, identity or third-party data integrations add real engineering even to a deliberately small build.
Investor or launch deadline
A fixed external date changes what gets cut first when scope and time collide.
Salvage from a prior attempt
Rebuilding a pivot costs less when the existing codebase and data are usable, more when starting genuinely fresh.
05Evidence and proof
Bets that got answered fast, one way or the other.
MVP proof is validated learning, not a feature list. Every record here waits for written client approval before production.
Explore case studiesA hypothesis tested and killed in three weeks, saving a year.
A founder believed a marketplace model would work. A scoped MVP proved supply-side demand did not exist before six figures were spent building the wrong thing.
- Time to validated answer
- 3 weeks
- Spend avoided
- Six figures
A pivot rebuilt in half the time of the original MVP.
The first version of Koru Health's product tested the wrong workflow. The pivot salvaged the architecture and reused the data model, cutting rebuild time sharply.
- Rebuild time versus original
- Roughly halved
- Architecture salvaged
- Most of the core
They told us which features to cut before we asked. The version that shipped answered the question in three weeks instead of the six months we planned for.
Sample · pending client approval
06Read this first
When an MVP is the wrong move
Building a test when the hypothesis is already proven wastes your runway. The exits are marked plainly. When the build is justified, it runs on React, Next.js and Node, with Postgres and cloud infrastructure sized to a startup's actual budget.
- Custom software development
The hypothesis is already validated
If customer interviews and existing data already answer the question, build the real product instead of testing what you already know.
You have committed customers waiting
If paying customers are already lined up, a scoped build serving them properly beats a deliberately minimal test.
You need a technical co-founder, not a vendor
If the gap is ongoing technical leadership rather than a defined build, this is the wrong shape of engagement entirely.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Fixed-scope sprint | The hypothesis is precisely stated | The metric and the call | The build and instrumentation |
| Iterative build | Learning will reshape scope weekly | Priorities each cycle | Engineering and measurement |
| Team extension | You need ongoing technical capacity | Product direction | Named engineers |
07Straight answers
Asked before the first sprint starts.
01How is an MVP different from a prototype?
A prototype demonstrates a concept. An MVP is real software real users can use, built specifically to test a hypothesis with genuine usage data. The distinction matters because a prototype cannot validate whether people will actually adopt something.
02How long does an MVP take to build?
Most MVPs ship in four to ten weeks, scoped to the hypothesis rather than a fixed feature list. A hypothesis that needs longer to test honestly is usually a sign the scope has crept beyond what an MVP should attempt.
03What happens to the code after the MVP proves out?
It becomes the foundation of the real product, not a throwaway. MVPs here are built on production-grade patterns specifically so the validated version does not require a rewrite to scale.
04Can you build an MVP for a technical co-founder search?
Yes, and it is a common reason founders arrive here. A working MVP demonstrates execution ability to a technical co-founder candidate in a way a pitch deck cannot.
05What does MVP development cost?
Scoped against the hypothesis and its integrations, typically as a fixed-price sprint. The pricing conversation starts from what needs proving, not from a generic startup package.
06Do you help define the hypothesis, or only build what we specify?
Both, and most engagements start with a scoping conversation that sharpens a vague idea into a testable hypothesis before any build estimate is given.
07What if the MVP proves the idea wrong?
That is a successful outcome, not a failed engagement. An MVP that cheaply disproves a bad idea has done exactly its job, and the pivot conversation starts from real data instead of another guess.