An MVP that proves the business, not just the demo.
From first workshop to a product real users pay for. Scoped ruthlessly, engineered properly — so v2 is an iteration, not a rewrite.
- Scoping workshop
- Build sprints
- Hardening & launch
- Evidence loop
The discipline is in what we refuse to build.
A minimum viable product is a bet: the smallest build that produces real evidence. Most first versions fail not because the engineering was weak but because the build answered a question nobody was actually asking — it demonstrated the pleasant parts of the idea and quietly avoided the one claim the business depends on. We scope to the riskiest assumption, cut everything that does not test it, and ship on infrastructure that survives success, because the failure mode we see most often is not an MVP that flops. It is an MVP that works, gets traction, and then has to be thrown away.
So the version we ship is deliberately narrow and deliberately real. Real users, real payments where money is part of the claim, real monitoring, real data you can query afterwards. A prototype tells you whether people like the screens; an MVP tells you whether they change their behaviour. The difference matters later, when the board asks what you learned and the honest answer needs to be a number rather than a set of positive conversations.
Every feature deferred is time returned to the launch date — and our scope ledger records each deferral with the reason and the evidence that would bring it back, so nothing is silently lost and nobody has to defend the same cut twice.
Four things a first version has to do.
An MVP has one job: produce evidence cheaply enough that being wrong is survivable. Everything below serves that, including the parts that look like over-engineering and are not.
Riskiest-assumption scoping
We identify the claim your business depends on and design the smallest product that tests it with real users and real money. That usually means one journey built properly rather than five built partially, and it means naming the assumption out loud in the workshop so the scope argument happens once, at the start, rather than every second week. What comes out is a written v1 boundary the whole team can point at.
Production-grade foundations
MVP does not mean fragile. Authentication, payments, monitoring and CI/CD are wired from the start — the parts you never want to rebuild and the parts that quietly decide whether v2 is an iteration or a restart. We use proven, well-understood pieces: TypeScript end to end, Next.js on the front, PostgreSQL underneath, deployment as code from the first commit.
Regular demo cadence
Working software at a regular rhythm agreed with you. You steer scope while it is cheap to steer, on a live staging environment rather than in a slide deck, and the demo is run against the same build that would go to production. Decisions taken in that session are recorded in the scope ledger the same day, which is why the launch date stays honest instead of drifting quietly.
Launch & measure
Analytics, funnels and feedback loops are built in, so the MVP produces evidence — not just screenshots. We agree the two or three numbers that would make you continue, pivot or stop before the build starts, and instrument them first. After launch we sit in the funnel review with you: the point of the exercise is a decision, and a decision needs a baseline it can be compared against.
How the work runs, day to day.
The scope ledger, kept in the open.
Scope arguments are expensive because they are repeated. Someone asks for a feature early on, it is cut, and later the same request arrives from a different direction with more urgency attached. The ledger ends that. Every request is written down with a decision, a reason and — where it matters — the evidence that would bring it back into scope. Nothing is refused; things are sequenced. It is a plain document your team can read on any day of the engagement, and it doubles as the honest first draft of the v2 backlog.
- Every request recorded with a decision, a reason and a trigger for revisiting it
- Like-for-like swaps are simply traded; expansions move the date, visibly, on the day they are agreed
- At launch the deferred column becomes the v2 backlog, already costed and ranked
The parts you never want to rebuild.
There is a short list of things that are cheap to do at the start and painful to retrofit: identity, payments, environments, deployment, error reporting, and a database schema that expects to be migrated. Every one of them touches everything else, so adding them later is not a task but a refactor. We install that list first, in its simplest correct form, then spend the remaining time on the product. It is the reason an Odeontech MVP can take traffic on launch day without a scramble.
- Environments, CI/CD and preview deployments before the first feature branch
- Identity, roles and audit fields designed once — retrofitting them touches every table
- Error tracking, uptime checks and a basic on-call path live before launch, not after the first incident
Evidence, not enthusiasm.
The most valuable output of an MVP is a decision you can defend. That requires numbers agreed in advance, instrumented before launch and reviewed on an agreed rhythm — otherwise the review turns into an argument about which anecdote is representative. We set the funnel with you in the scoping workshop: the activation step, the moment of value, the paid conversion if money is part of the claim. Then we watch it together at a rhythm agreed with you and treat stopping as a legitimate result. An MVP that produces a clean no has done its job.
- Two or three success metrics agreed before the build, instrumented before launch
- Regular funnel reviews, at a rhythm agreed with you, with the deferred backlog open beside the numbers
- Qualitative feedback captured against the same journeys the metrics measure
The same build, three different stakes.
A date you can raise against.
Funding conversations run on evidence and timing. You get a scope band after the workshop, regular demos you can screen-record, and a launch date that moves when you choose to expand scope. The scope ledger doubles as the story of what you decided and why, which is a better answer in a diligence conversation than a roadmap slide.
- Scope band agreed after the paid scoping workshop
- Regular demos on a live environment, not a prototype
A new product without a new problem.
Inside an enterprise, the hard part of a first version is rarely the build — it is procurement, identity, data residency and the security review. We plan those at the start rather than discovering them late, and we build to the standards described on our security engineering page so the internal review has something to approve rather than something to question.
- Security and data-residency questions answered in phase one, in writing
- SSO, logging and access control designed for your existing estate
- A handover path into an internal team, or into a dedicated team with us
A codebase you would have written.
You inherit this. So it is typed end to end, tested where the risk is, deployed by pipeline, and documented in the repository rather than in a handover meeting. No private build steps, no machine that only one person can run, no secret in a chat message. Your engineers review our pull requests from the first sprint if you want them to, and can be merging their own as soon as they choose.
- One language across client and server, with a schema-first API contract
- Tests concentrated on money, auth and data integrity rather than spread thin for coverage
- Infrastructure as code, so the environment can be rebuilt without us
What is standard, and what is shaped per product.
Four phases, and working software early.
Scoping workshop
Assumption mapping, user journeys, and the scope ledger: what is in v1, what is deliberately deferred, and why. We work through the business claim being tested, the two or three numbers that would prove or disprove it, and the constraints that are real — regulatory, commercial, technical — rather than assumed. The workshop is a paid, standalone engagement and its output is delivered to you: the ledger, the journeys, an architecture sketch and a costed band.
Build sprints
Regular demos, a live staging environment from the first sprint, and scope decisions made together as evidence arrives. Each cycle opens with what shipped and closes with what the next cycle buys, so trade-offs are made while they are still cheap. Foundations land first — identity, payments, delivery pipeline, migrations — then the journey under test is built end to end rather than screen by screen, so there is always something a real person can complete.
Hardening & launch
Security review, load sanity checks, store or App Review submission where a mobile client is in scope, DNS cutover, and instrumentation for the metrics that matter. We test the failure paths deliberately: a declined payment, an expired session, a slow third party, a duplicate submission. Launch itself holds no surprises: the pipeline that has been deploying to staging throughout the build is the same one that deploys to production.
Evidence loop
Regular funnel reviews, at a rhythm agreed with you. Double down, pivot, or stop — the MVP’s job is to make that decision cheap, and the ledger makes the next increment easy to price. Some clients continue with us into a longer build or a dedicated team; some take the codebase in-house with a handover period; some stop, which is a good outcome delivered early. All three are planned for from the start.
What is on the table at launch.
- A deployed product with real users on production infrastructure
- Scope ledger — what shipped, what is deferred, and why
- Analytics and funnel instrumentation with a metrics baseline
- A costed, evidence-ranked v2 backlog
- CI/CD with preview environments and a rehearsed rollback
- Architecture notes and runbooks written in the repository, not in a meeting
When this is the right call.
Choose an MVP when there is a specific claim you cannot answer from a spreadsheet or a survey — that a segment will pay, that a workflow can be moved off email, that a channel converts, that an operational process survives contact with real volume. It fits a founder who needs evidence before the next raise, a corporate team with a hypothesis and a budget cycle, and any product where the fastest route to certainty is putting a narrow, working version in front of real users. If you have not yet decided which claim matters most, start with Product Discovery.
Look elsewhere when the requirement set is already known and agreed, contractually or by regulation: that is a full build, and pretending otherwise just renames the project — see Custom Software Development. Look elsewhere when the real problem is an existing system that has stopped moving, where modernisation or legacy re-engineering is the honest answer. And be cautious when nobody on your side can make a scope decision quickly: regular steering is what keeps an MVP small, and without it the build silently becomes a slow v1.
Frequently asked questions
What this connects to.
What is the one thing your product has to prove?
Name the assumption and who would have to behave differently. An engineer reads it and replies in writing with a view of the smallest build that would settle it.