Find the riskiest assumption
Before scope, we name the thing that has to be true for this business to work — demand, willingness to pay, a workflow people will actually change. The MVP exists to test that, not to impress anyone.
Salt · Build
From idea to a product real users can touch
A focused MVP, scoped around the single assumption that would kill the business if it turned out to be wrong.
Founders rarely fail by building too little
They fail by building too much of the wrong thing — six months of features aimed at a market that was never asked. In 2026 the bottleneck is not engineering capacity. AI has made building cheap enough that scope discipline is now the scarce skill.
So the first argument we have with you is about what to cut. It is the most valuable part of the engagement, and the part most suppliers skip because agreeing is easier to sell.
What we do
Cut the scope, in writing
We reduce the roadmap to the three to seven features your core flow cannot function without, using MoSCoW and RICE so the cuts are arguable rather than arbitrary. Everything else goes on a dated v2 list instead of into the build.
Choose the right kind of MVP
Single-feature, concierge, or no-code — matched to the assumption being tested. Sometimes the fastest honest answer does not require a codebase at all, and we will tell you when that is the case.
Build fast, with senior review
AI-accelerated delivery under senior engineering review, so you validate in weeks without inheriting code that has to be thrown away the moment it works.
Instrument for learning
Analytics, funnels and feedback loops from the first release. Launch is the beginning of learning, not the end of the project — an MVP with no measurement is just a small product.
What you get
- A working MVP in the hands of real users
- A written scope with the cut list and the reasoning behind it
- A validated — or honestly invalidated — core hypothesis
- Instrumentation: funnels, events and a dashboard you can read
- A prioritised v2 backlog based on evidence rather than opinion
- A recommendation: iterate, scale, or stop
How the build runs
- 01
Discover
The problem, the user, the riskiest assumption, and the one metric that will settle it.
- 02
Accelerate
Scope, cut, and build — timeboxed, with the smallest thing that can produce a real answer.
- 03
Refine
Put it in front of real users, watch the funnel, and separate what they say from what they do.
- 04
Elevate
Decide with the evidence: iterate, scale into a full product, or pivot before the money is gone.
How we scope
- Prioritisation
- MoSCoW RICE Assumption mapping Timeboxing
- MVP types
- Single-feature Concierge No-code Wizard of Oz
- Build
- React / Next.js Node.js Supabase AI-accelerated delivery
- Measurement
- Funnel analytics Session review User interviews Cohort retention
Numbers we move
- Time to first real user
- Cost to validate — what the answer actually cost you
- Activation through the core flow
- Retention in the first cohorts
- Evidence a serious investor will accept as traction
Frequently Asked Questions
How fast is an MVP?
Weeks rather than quarters, but the honest answer depends entirely on what we cut. Anyone quoting a fixed number of weeks before seeing the scope is quoting a number, not a plan.
Will the MVP code survive into the real product?
Often, partly. We build with senior review specifically so the foundation is reusable, but an MVP is optimised for learning speed. We tell you honestly which parts are keepers and which are scaffolding.
What if the MVP shows the idea does not work?
Then it did its job, at a fraction of the cost of finding out later. A clean negative answer in eight weeks is a good outcome, and we would rather deliver that than a beautiful product nobody wanted.
Tell us about your idea
Bring the idea and the assumption you are least sure about. We will come back with what to build first — and, more usefully, what not to.