What a custom build actually costs, and what moves the number
A production-grade MVP runs $35,000 to $250,000 and beyond. Most land between $35,000 and $90,000; the builds that reach the top of the range are not the ones with the longest feature list, they are the ones touching the most systems. Feature count is the number clients estimate with, and it is the weakest predictor in the set.
Three things move the figure more than anything else. How many external systems the application has to integrate with, because every integration is a contract with something you do not control. Whether real authentication and permissions are needed on day one, because retrofitting a permission model into a live system is close to a rewrite. And how much existing data has to migrate in, because migration cost scales with how messy the source is, not with how many rows it holds.
| Single-user tool, no integrations | $35,000–$50,000. One user type, no external systems, data entered rather than migrated. 8–10 weeks. |
|---|---|
| Multi-user with real permissions | $50,000–$90,000. Roles and access rules designed up front, audit trail, several user types with genuinely different views. 10–16 weeks. |
| Payments, CRM or third-party integrations | $90,000–$150,000. Each integration adds error handling, reconciliation and a failure mode that must be designed rather than discovered. 14–20 weeks. |
| Regulated data or complex migration | $150,000–$250,000+. Compliance evidence, data residency, and a migration from systems whose data quality is the real project. 20+ weeks. |
The line between an MVP and a prototype
A prototype proves an idea to a person. An MVP survives contact with real users, real data and real load. They cost different amounts because they are different artefacts, and most disappointing builds are a prototype sold as an MVP.
The practical difference is what happens on the bad day. A prototype has no environment separation, so every change is deployed by hand and every deploy is a risk. It has no tests, so nobody can safely change what already works. It has no error handling worth the name, so a failed third-party call becomes a blank page. None of that matters in a demo and all of it matters in week three of real use.
A quote promising six weeks for a production system is almost always pricing the prototype. That is a legitimate thing to buy — sometimes proving the idea is exactly the right next step — but it should be bought knowingly, with the second build already in the plan.
What we build into every application, before anyone asks
- Environment separation from day one — a place to change things that is not production. Without it, every later fix is a gamble.
- Authentication and a permission model designed at the start. Bolting access control onto a live application is the single most expensive retrofit in this work.
- Tests around the code most likely to change, not blanket coverage. Coverage where you actually work is what makes future change safe; coverage everywhere is a number that impresses and does not help.
- Structured logging and error tracking, so a production problem is a query rather than an archaeology project.
- A documented data model. The thing that most often forces a rebuild two years later is a schema shaped around the first customer instead of the business.
- A deployment path anyone on the team can run. If one person is the only one who can ship, that is an availability risk, not a technical detail.
The cost nobody budgets for: the quarter after launch
An application that reaches real users generates change requests immediately, and they are the most valuable signal the project will ever produce — real people telling you what is actually wrong. A build with no budget left for the three months after launch tends to get abandoned exactly when it starts being useful.
Plan roughly 20 to 30 percent of the build cost for the first quarter post-launch. If a quote says nothing about what happens after go-live, that is the question to ask before comparing prices, because a cheaper build that ends at launch is usually more expensive by month six.
How to evaluate anyone quoting a custom build
- Ask what happens in the first week after launch, and who does it. A vague answer here predicts an abandoned application.
- Ask which parts they would NOT build custom. Anyone who thinks everything should be bespoke is selling hours, not judgement.
- Ask to see the data model before the design. The schema is the decision that is expensive to reverse; screens are not.
- Ask how they handle a third-party API being down. The answer tells you whether they have run something in production.
- Ask who owns the code and the infrastructure accounts. If the answer is not unambiguously you, resolve it before signing.
- Ask what they would do if the budget were 30 percent smaller. A good answer names what gets cut; a bad one offers the same scope for less.
When custom is the wrong answer
If a platform already models your workflow and your edge is not in the software itself, configure the platform. We deliver on all the major ones, so this recommendation costs us the build and we make it regularly — a custom application whose only advantage is that it is yours will lose to a configured platform on both cost and reliability.
Custom earns its cost when the workflow is genuinely unusual, when the workflow is itself the competitive advantage, or when the integration surface is so specific that no platform models it without more customisation than a build would take. If none of those is true, the honest recommendation is to buy.