AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms6–10 wks
First release
Usable, not a demo
Scoped
Typical MVP
Fixed scope, fixed price
1
Workflow done properly
Not five done partially
100%
Code yours at launch
From the first commit
What an MVP actually is
A narrow product that works, not a broad one that almost does
The word gets used for two completely different things, and confusing them is the most expensive mistake in early-stage software. One is a product. The other is a prototype wearing a product's clothes.
Minimum means narrow, not unfinished
One workflow, taken end to end, that a real user can complete without help and without apology. The scope is small; the quality is not. A product that does one thing properly earns feedback you can act on. A product that does five things halfway earns a list of bugs.
Viable means someone would pay
The test is not whether it demos well. It is whether a user would choose it over their current workaround — the spreadsheet, the email thread, the manual process. If the answer is no even when it works perfectly, the problem is the hypothesis and no amount of engineering fixes it.
It is production software
Real authentication, real data handling, real error states, deployed on infrastructure you own. Cutting those is how a successful MVP becomes an unshippable liability the week you try to scale it — and a successful MVP is exactly the case you should be planning for.
It is designed to be thrown away in part
Some of what you build will be wrong, and the architecture should make it cheap to find out. Clear service boundaries and a data model you can migrate matter more at this stage than test coverage on code that may not survive the quarter.
Scoping
How we decide what goes in and what waits
Most MVP overruns are scope decisions made by accident. These are the four we make on purpose, in this order, before anything is estimated.
| Step | What happens |
|---|---|
| 1 · One user, one job | Name the single user and the single job they hire the product for. Every feature request afterwards is measured against that sentence, which is what makes saying no a decision rather than an argument. |
| 2 · The path to value | Map the shortest route from signing up to the user getting the thing they came for. Everything on that path is in scope. Everything beside it — settings, admin, reporting, the second persona — waits. |
| 3 · What must be real | Decide which parts genuinely need to work and which can be operated manually behind the scenes. Concierge delivery of a hard feature is often the right call for a first release and saves six weeks. |
| 4 · The measurement | Agree before launch what result would mean continue, what would mean pivot, and what would mean stop. An MVP that ships without that agreement produces opinions instead of evidence. |
This is discovery, it takes two to four weeks, and the document is yours whether or not you continue building with us.
What it costs
MVP development cost, without a discovery call first
Real ranges for MVPs we have actually delivered. The variable that moves a quote most is not feature count — it is how many external systems the product has to agree with, and how well documented those systems are.
| Engagement | Typical range | Timeline | What it buys |
|---|---|---|---|
| Discovery only | Scoped per engagement | 2 – 4 weeks | Clickable prototype, architecture, risk list, costed scope. Credited against the build if you continue. |
| Lean MVP | Scoped per engagement | 6 – 8 weeks | One workflow end to end, single user type, one or two integrations, deployed on your infrastructure. |
| Funded MVP | Scoped per engagement | 8 – 10 weeks | Multiple user roles, billing, admin tooling, the integration set a real customer expects on day one. |
| MVP to v1 | Scoped per engagement | 3 – 6 months | Continuing from a validated MVP into the product a sales team can sell without caveats. |
Ranges assume US-based senior engineers and include QA, DevOps and delivery management rather than quoting them separately. A quote materially below these bands usually means one of those three was left out of the scope, and it reappears later as a change request.
How the build runs
Ten weeks you can audit
Every two weeks there is working software on a preview URL you can click. You review the product rather than a status deck, which is what stops a first release drifting quietly past its date.
What you actually get
Everything a first release needs, and nothing it does not
An MVP is still production software, so the unglamorous parts are not optional. What is optional is the work that only pays off at a scale you have not reached.
Built in
Authentication with real session handling, a data model designed to be migrated, structured logging, error tracking, and automated deploys from a repository you own.
Built in
A staging environment that matches production, basic analytics on the path to value, and enough test coverage on the paths that would lose data if they broke.
Deliberately deferred
Multi-region infrastructure, aggressive caching layers, microservice decomposition, and anything else designed for load you cannot yet demonstrate.
Deliberately deferred
Exhaustive admin tooling, a second user persona, configurable everything, and the reporting suite that gets requested before anyone knows which numbers matter.
Chosen for boredom
Mature frameworks and managed databases — React or Next.js, Rails or Django, Postgres, one cloud provider defined in Terraform. Interesting technology is a cost you pay at 3am.
Chosen for your team
Where you have in-house engineers who will inherit this, their stack wins over a marginally better one they would have to learn under pressure. We will say so even when it is less interesting to build.
The deferred list is not a downsell. Each item is a real cost with a real payoff at a scale you may never need — and if you do reach it, a clean data model is what makes adding them cheap.
Where MVPs go wrong
Five failure modes we are asked to rescue
None of these is a technology problem, which is why adding engineers rarely fixes them.
Minimum got confused with cheap
Quality was cut instead of scope. The result works in a demo and falls over with real users, and the feedback you get is about defects rather than about whether anyone wants it.
It was built for the investor, not the user
Breadth wins pitches and depth wins retention. A product built to look complete in a deck tends to be shallow everywhere and compelling nowhere.
No decision was defined before launch
Without an agreed threshold, every result is ambiguous and the team argues about interpretation for a month. Decide what continue, pivot and stop look like while nobody is emotionally invested.
The prototype became the product
A throwaway built under time pressure quietly turns into the foundation because it works. That is survivable only if somebody decides it deliberately and budgets the cleanup.
Scaling was designed for on day one
The opposite failure. Multi-region infrastructure for a product with no users costs months and buys nothing. Build for the load you can prove, and make the data model easy to migrate.
Related
Related services
What founders usually need next, or instead.
Questions
Buying MVP development
What founders ask before a first call.
A lean MVP is the smaller of the two shapes, a funded one the larger, with discovery in front of either. The table above sets out what each includes.
The variable that moves a quote is not feature count, it is integrations — the number of systems your product has to agree with, and how well documented those systems are. Features are largely predictable; somebody else's poorly documented API is not.
Six to ten weeks for the build, after two to four weeks of discovery. That assumes decisions come back inside a week and there is one person on your side who can approve scope.
The schedule risk is almost never engineering capacity. It is waiting on access to a system, a legal review, or a decision that needs three people in a room.
A prototype demonstrates; an MVP is used. A prototype can be clickable screens with no backend, built to test whether an idea communicates. An MVP has real authentication, real data and real error handling, because real people depend on it.
Both are legitimate and they cost very different amounts. Being clear about which you are buying is the single most useful thing you can do before asking for a quote.
Yes, from the first commit. Source, infrastructure defined in Terraform under your own cloud account, CI configuration and documentation transfer to you at launch or on request at any point before it.
Nothing we build locks you to us. If a framework or hosting arrangement would make leaving expensive, that is a commercial decision dressed as a technical one and we do not make it.
Three honest outcomes. The hypothesis holds and you continue into v1, usually with a standing pod. It partly holds and you pivot the scope with most of the platform intact. Or it does not hold, and you have learned that for the price of ten weeks rather than a year.
We will tell you which one the data says, including when it is the third.
Frequently, and it is often the better arrangement when the in-house team is strong but short on capacity or missing a specific skill. Our engineers join your repository, your board and your standups.
The alternative — a sealed-off vendor team delivering over the wall — tends to produce software your own engineers are reluctant to own afterwards, which is a bad position to be in right after launch.