SERVICE
MVP development
The smallest thing that tests the riskiest assumption — built properly.
What this actually is
An MVP is an experiment with a user interface. Its job is to answer the riskiest assumption in your business with real behaviour rather than opinion — which means the correct scope is defined by the question, not by what would be impressive to demo.
The two ways it fails are symmetrical. Build too much and you have spent the runway before learning anything. Build something disposable and, if it works, you spend the next year rewriting it while competitors ship features. The middle is narrow: small scope, sound foundations.
What we do
Assumption mapping
Naming the belief that would kill the business if wrong, and designing the smallest build that tests it.
Ruthless scoping
What ships and what explicitly does not, written down, because scope creep is what kills MVPs rather than technical difficulty.
Fast, sound build
Boring proven technology, sensible structure, no cleverness that costs a rewrite later.
Instrumentation
Analytics from day one, because an MVP that ships without measurement has not run the experiment.
The stack
What it connects to
Integration surface is the honest driver of effort — ten systems is not ten times one system.
- Stripe for payments from day one
- Auth — Clerk, Auth0 or Supabase
- Analytics — PostHog or Mixpanel
- Email and transactional messaging
- Error tracking
- Whatever your first integration partner requires
How a project runs
Definition
3–5 days
The assumption, the metric that tests it, and the scope that fits.
Build
4–8 weeks
A working product in front of real users.
Learn
2–4 weeks
Instrumented usage and a decision: continue, change direction, or stop.
Scale or stop
ongoing
Foundations to build on if it worked; an honest ending if it did not.
Where teams use it
Marketplaces
Testing whether both sides show up, usually with far more manual operation behind the scenes than the interface suggests.
SaaS
One workflow done well for one segment, rather than a thin version of everything.
AI products
Establishing whether the model is good enough to be worth a product before building the product around it.
Marketplace add-ons
Launching inside an existing ecosystem where distribution is solved and the product is not.
When this is the wrong answer
If you already know customers want it and are trying to build fast, that is not an MVP — it is version one, and it should be scoped and resourced as such.
An MVP with no users is not an experiment, it is a prototype. Distribution needs to exist before the build starts, not after.
Cutting testing and deployment discipline to move faster costs more within about six weeks. What should be cut is scope.
Some assumptions are cheaper to test without software. If a landing page or twenty conversations would answer it, do that first — we will say so.
Proof
SiteChat & Estimate256: RAG bots and ML estimation in production
Zero-code website chatbot platform plus a domain-tuned ML estimation engine — two production systems on one modern stack.
Frequently asked questions
How much should an MVP cost?
Less than you can afford to lose, because it might teach you the idea is wrong — which is a successful outcome. Tell us the budget and we will scope the sharpest experiment that fits it.
Will we have to rewrite it?
Not if it is built on standard technology with a sensible structure. What gets replaced over time is early product decisions, not the foundations — which is why we do not use throwaway tooling to save two weeks.
Can you help decide what to build?
That is the first few days. The most valuable thing we do on some MVPs is remove two thirds of the scope.
Who owns the code?
You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.
What does it cost?
We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.
What should we cut?
Everything that is not the experiment. Admin panels, settings pages, onboarding flows and edge cases can be manual at first — several successful MVPs ran on a founder doing the "automated" part by hand.
How do we know if it worked?
The metric is agreed before the build, with a threshold that would make you stop. An MVP with no failure condition is not an experiment.
What if we need to pivot?
That is a successful outcome, not a failure. Building on standard technology with a sensible structure means a pivot costs weeks rather than the whole codebase.
Should we raise before or after?
Not our call, but a working product with real usage data is a materially different conversation from a deck. That is the main non-product reason MVPs are worth building.
How do we start?
A scoping call, then a short written proposal with scope, sequence and the assumptions it rests on. If we think you should not do this, or should do a smaller version first, that is what the proposal says.
Can our team take it over afterwards?
That is the intended end state. Standard technology, decisions documented as they are made, and handover sessions with your engineers. If a system can only be maintained by us, we built it wrong.
Related
Before you choose anyone
Written to be useful whether or not you hire us — including the parts that argue against hiring an agency at all.
How to choose an AI development company
ReadAI agency vs in-house team
ReadCustom AI vs off-the-shelf
ReadOffshore vs local AI development
ReadAI Voice Agents: The Complete Guide for Businesses (2026)
ReadRAG vs Fine-Tuning: Which Does Your Business Need?
ReadHow Much Does AI Development Cost in 2026?
ReadMVP Development for Startups — tell us the scope
Tell us what you are building. We reply within one business day.