For the idea that has not yet earned its runway
Build Your MVP
A founder with twelve months of runway does not get to build the wrong thing twice. Before a single sprint starts, the real decision is whether this idea deserves the runway at all, and what the smallest honest test actually looks like. This practice starts from that bet, not from a feature list, and treats the runway itself as the constraint worth protecting.
How the runway decision gets made
Cheaper tests, scope cuts and when code genuinely becomes the fastest way to an answer.
90 secSample frame · video pending01Before writing a single sprint
The real question is whether to build code at all.
Founders often reach for a build when a cheaper test would answer the same question. Four checks separate a hypothesis that needs software from one that needs a landing page and a phone call.
Would a fake front end answer it faster?
A landing page with a waitlist, or a manual process behind a real form, sometimes proves demand cheaper than any build could.
What is the one metric that decides this?
If nobody can name it in a sentence, the build cannot be scoped correctly no matter how small it gets cut.
How much of your runway can this test cost?
A test that eats half your remaining runway had better be the only test you get to run.
What would prove the idea wrong?
An MVP that cannot fail is not testing anything real, so the losing outcome gets defined before the build starts.
| Landing page test | Manual process | Real MVP build | |
|---|---|---|---|
| Cost | Lowest | Low to moderate | Highest of the three |
| Speed to a signal | Days | One to two weeks | Several weeks |
| What it actually proves | Interest, not usage | Willingness to pay or act | Real, sustained usage |
| When it fits | Unproven demand | A workflow, not yet software | The hypothesis needs the product itself |
02Agreed before the first sprint
The ledger that keeps the test honest
MVP engagements drift when the definition of done quietly grows mid-build. This ledger fixes what you bring, what gets built, what comes back, and what stays entirely your call regardless of the result.
- Your side
You bring
- The idea and the belief behind it, stated plainly
- How much runway you are willing to spend testing it
- Any early signal already gathered, even informally
- Our side
We build
- A sharpened, single-sentence hypothesis worth actually testing
- A recommendation on the cheapest way to test it, code or not
- A build scoped only if code is genuinely the fastest test
- Your side
You receive
- A clear verdict on whether the idea earned real investment
- Either a working MVP or an honest reason not to build one
- A record of the reasoning, useful for the next idea too
Never leaves you
- The decision to proceed, pivot or abandon the idea
- Full ownership of the hypothesis and any resulting build
- The runway not yet spent
Where the line sitsSometimes the right answer is not to build anything yet. That verdict costs a fraction of a wrong MVP and is treated as a legitimate outcome here.
03A verdict, not a vibe
Four stages, each closing on evidence
A test that drifts into a full build has already lost the plot. This system closes each stage with something you can act on before the runway moves any further.
Test the idea before scoping any build
The hypothesis is sharpened and checked against cheaper tests first, so code only gets written once it is genuinely the fastest route to an answer.
Cheaper tests ruled out firstCut the plan to the load-bearing minimum
Each planned feature is tested against one question: does removing it change whether the hypothesis gets a fair test.
Every feature earns its placeShip with the metric already instrumented
The build reaches real users with the deciding metric already live, so the first data point actually means something.
A metric live before day oneRead the result against the runway
The data says persist, cut further or stop, and the call gets made while runway remains to act on it.
A call your runway can act on
04What actually moves the number
Four drivers, priced from the runway
Pricing here follows the runway and the hypothesis, not a startup package. These four factors change the number more than anything else.
How much runway remains
A test built against six weeks of runway looks different from one built against six months, because the cut points move with the deadline.
Integrations the hypothesis genuinely needs
Payments, identity or third-party data integrations add real engineering even to a deliberately minimal build.
How settled the hypothesis already is
A sharply stated hypothesis costs less to test than one that still needs a conversation to become testable at all.
Whether a cheaper test already ran
A landing page or manual process that already gathered signal narrows what the real build still needs to prove.
05Evidence and proof
Bets that got a fast, honest verdict.
MVP proof here is a runway protected and a verdict reached fast, not a feature list shipped. These previews carry that standard while written client approvals are collected.
Explore case studiesA manual process that answered the question before any code shipped.
Tern believed a routing hypothesis could reduce delivery delays. A manual process behind a simple form proved demand in two weeks, before any software got built.
- Time to a demand signal
- 2 weeks
- Engineering spend before the signal
- None
A validated answer delivered nine weeks before the runway ran out.
Vela Ledger had a fixed date before the next funding conversation. A build timed backward from that date delivered a validated metric with weeks to spare.
- Weeks of runway remaining at delivery
- 9
- Metric instrumented before launch
- Yes, from day one
They talked us out of half the plan before we spent a cent building it.
Sample · pending client approval
06Read this first
When building software is the wrong first move
Writing code before a cheaper test has been tried spends runway a landing page could have saved. The exits are marked plainly. When a build is justified, it runs on React, Next.js and Node, sized to a startup's actual budget.
A landing page has not been tried yet
If nobody has tested the idea with a page and a waitlist, that costs a fraction of a build and often answers enough on its own.
- Build Your Product
The idea is already validated
If customer interviews and real usage already confirm the hypothesis, the next move is building the product, not testing it again.
- MVP Development
You need the technical build scoped in detail
The execution detail behind an MVP, architecture, integrations and delivery mechanics, lives in a dedicated technical practice.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Validation sprint | The idea needs a fast, cheap first signal | The metric and the call | A landing page, manual process or minimal build |
| Fixed-scope MVP | The hypothesis is precisely stated | Priorities within the cut list | The build and instrumentation |
| Runway-timed build | A deadline is forcing the pace | What ships before the deadline | A build timed backward from that date |
07Straight answers
Asked before the runway gets spent.
01Should we test the idea before writing any code?
Usually yes, if a landing page or a manual process can gather the same signal cheaper. Code becomes the right test once the hypothesis genuinely needs the product to be real.
02What if we already have a bloated MVP plan?
Bringing an existing plan is common, and the first move is cutting it back to what the hypothesis actually needs. Most plans shrink considerably once every feature is tested against that one question.
03Does the build change if our runway is short?
Yes, a fixed runway deadline sets the pace backward from that date rather than forward from a feature list. The metric gets instrumented early enough to leave real weeks for the test itself.
04What happens if the test proves the idea wrong?
That is a successful outcome, not a wasted engagement. An idea disproven cheaply protects the runway for whatever gets tested next, and the reasoning gets documented for that decision.
05How is this different from your MVP development service?
This page is the decision layer: whether to bet runway on this idea and what the smallest honest test looks like. The build execution itself is scoped in the MVP Development practice.
06Can you help define the hypothesis, not just build it?
Yes, most engagements start with a scoping conversation that sharpens a vague idea into something testable. A vague idea cannot be scoped into a build estimate honestly.
07What does testing an idea cost?
It follows how much runway remains and how settled the hypothesis already is. A landing page test costs a fraction of a scoped build, and the assessment states which fits before committing to either.
08What happens to the code if the idea gets validated?
It becomes the foundation for the real product rather than a discard. Builds here follow production-grade patterns from the start specifically so validation does not force a rewrite.