“How much will this cost?” is the first question every custom software project starts with, and the one no honest partner can answer on the spot. Push for a number and you get a shrug, or a range so wide it is useless for planning. It feels evasive. It is not. The cost of custom software genuinely has no single answer, because it is decided by a handful of variables that differ from one project to the next, and any firm figure offered before those variables are known is a guess dressed up as a quote.
That does not leave you stuck. You cannot know the price up front, but you can understand what drives it, place your own project on that scale, and know whether you are looking at a lean, moderate, or heavy build before you talk to anyone. This piece gives you that: the variables that decide your number, a quick way to profile your own project, why every honest estimate is a range, and the costs the quote never shows.
Why No One Gives You a Straight Number
The reason a good partner hesitates is the same reason a bad one does not. Two projects described in the same words (“we need a customer portal”) can sit an order of magnitude apart in cost, depending on how many user roles they carry, how many systems they touch, whether health or payment data is involved, and how the team is staffed. The brief never contains the cost. The variables do.
So the partner who quotes you a confident number in the first meeting is not more capable than the one who asks for scope first. They are simply willing to name a figure they cannot yet stand behind, which you will pay for later through change requests when reality arrives. “It depends” is the correct answer. What matters is whether they can tell you what it depends on.
The Variables That Decide Your Number
Six drivers do most of the work. None of them is a price on its own, but together they explain why one build is cheap and another, superficially similar, is not.
| Cost driver | Leaner when… | Heavier when… |
|---|---|---|
| Project complexity | Simple workflows, few user roles | Complex domain, real-time, high concurrency |
| Integrations | Standalone, or one clean API | Many systems, especially legacy or ERP |
| Compliance & security | No regulatory obligations | HIPAA, PCI-DSS, SOC 2, formal audits |
| Data migration | Greenfield, no legacy data | Large, messy data from old systems |
| UX depth | Functional, standard components | Bespoke design system, high polish |
| Engineering model | Offshore team | Senior, onshore-led team |
The important thing is that these compound. A project that is simple, standalone, unregulated, and greenfield sits at the floor. Add a handful of integrations, a compliance regime, and a data migration, and you are in a different budget entirely. Not because anyone marked the price up, but because each driver is real work that has to be done. This is why comparing two projects by their one-line description tells you nothing about their cost.
Find Your Project’s Cost Profile
Rather than guess where you land, run your project through the drivers below. Pick the closest option in each row and you will get a relative profile (lean, moderate, or heavy), plus the drivers pushing your cost up the most. It is a way to think, not a quote.
Self-assessment
What's your project's cost profile?
Pick the closest option in each row. No email, nothing saved — this runs entirely in your browser.
Choose one option in each row to see your cost profile.
Your cost profile:
Your biggest cost drivers: .
Want a real number for your specific project?
Give us your scope and we will turn your cost profile into a defensible estimate, not a guess.
Why Every Estimate Is a Range, Not a Number
Even with the drivers understood, an early estimate is still a range, and it should be. An estimate made at the start of a project is made when the least is known about it. Software carries an unusual amount of hidden detail: edge cases nobody listed, integration quirks that only appear on contact, and requirements that clarify themselves only once people see working software and react to it.
Good estimation works with that reality instead of hiding it. It gives you a range that narrows as scope firms up and the first real increments ship, and a mature partner will tell you their hit rate, meaning how often past projects landed inside the range they first quoted. A single, confident number offered before any of that is a sales artifact, not an engineering one. The precision is claimed, not earned, and it is usually the number that doubles.
The Costs the Quote Doesn’t Show
The build quote is not the whole bill, and the gap between them is where budgets go wrong. When you compare quotes, add back the work that has to happen regardless of who does it:
- Quality assurance and testing: thin testing is the easiest line to cut from a quote and the most expensive to skip.
- Project management and coordination: someone has to keep scope, timeline, and communication aligned; a quote with none has hidden it in the engineers’ time.
- Integration work: connecting to your other systems is real effort, not a footnote.
- Cloud and infrastructure: the software has to run somewhere, and that cost continues after launch.
- Change requests: an optimistic quote leaves room to raise the number once you have committed.
- Post-launch support and maintenance: the largest forgotten cost, because software is owned, not just built.
- Documentation and knowledge transfer: the difference between owning your system and being locked in to whoever built it.
This is why the cheapest quote is so often the most expensive. A lower number usually means more of the list above was left out, and every item you did not pay for at the start you pay for later, at a worse price. Compare total cost of ownership, not the headline figure.
Also read
- Whether to build custom at all, or buy off-the-shelf
- What a dedicated team really costs vs staff aug and project work
- How to choose the right development partner
- The 12 questions to ask a partner before you sign
How to Get a Number You Can Trust
The only honest path from “it depends” to a figure you can budget against is scope. A short discovery exercise, mapping the real requirements, the integrations, the data, and the compliance load, turns the drivers above into a defensible estimate for your specific project, with a range that reflects what is still unknown. It is a small investment that replaces guesswork with a number you can take to a board, and it is the step a good partner will insist on before quoting.
The Bottom Line
There is no price list for custom software, and any partner who behaves as if there is one is telling you something about how they will work later. But “it depends” is not the end of the conversation. It depends on complexity, integrations, compliance, data, experience, and team: variables you can read, profile, and plan around. Understand those, insist on a range rather than false precision, count the total cost rather than the build quote, and you will not be the buyer who found out too late that the cheapest number was the most expensive one.
Turn 'it depends' into a real estimate
Bring us your scope. We will map the drivers and give you a number you can plan against.