Guide
What custom software development actually costs
Published 2026-08-14 · Updated 2026-08-14
The cost of custom software is decided by integrations, data migration and edge cases — almost never by the number of screens. This guide gives you the estimation method rather than a price list, because a range quoted without knowing your integrations is a number with no information in it.
Why price lists for custom software are misleading
A published range for "a custom CRM" or "a marketplace" describes a product category, and custom software is by definition not a product category. Two systems with the same description can differ by a factor of five because one of them writes to a legacy database that nobody documented.
Verttical does not publish rate ranges on this site. What follows is the method used to arrive at a real figure, which is reproducible: you can run it yourself, on your own project, before talking to anyone.
The five drivers, in order of impact
Ranked by how much they move a real estimate. The first two routinely account for more than half the budget, and neither is visible in a feature list.
| Driver | What raises it | Typical share of effort |
|---|---|---|
| Integrations | Systems without APIs, undocumented behaviour, rate limits, vendors who must approve access | Often the largest single block |
| Data migration | Old data with inconsistent shapes, duplicates, records nobody can explain | Large and consistently underestimated |
| Edge cases | Exceptions the business handles manually today and nobody wrote down | Grows through the project |
| Decision latency | Days waiting for an answer about how a rule should behave | Pure overhead, entirely avoidable |
| Compliance and access control | Audit trails, roles, data residency, regulated sectors | Small or enormous, no middle |
Number of screens is deliberately absent. A four-screen system reconciling three legacy databases costs more than a forty-screen system that owns its own data.
A worked estimate you can run yourself
Four numbers you already have or can get in an afternoon. It produces a range, not a quote, and a range is the honest output at this stage.
01
Count the integrations
List every system the software must read from or write to. Mark each one as documented API, undocumented API, or no API. The third category is the expensive one, and one of those can outweigh five of the first.
02
Size the data you are bringing
How many records, how many years, and how many of those years predate whatever cleanup happened last. Data older than the current process is where migration effort hides.
03
Write down the exceptions
Ask the people doing the work today what they do when the normal path does not apply. Every answer that starts with "well, usually we just…" is scope that nobody has costed.
04
Multiply team by duration, then add a third
Take the team size a partner proposes, multiply by their blended rate and by the number of months, then add roughly a third for the exceptions from step three. If the result shocks you, the useful conversation is about cutting scope, not about the rate.
The cheapest thing you can do to lower the number
Answer questions faster. Development time is inexpensive compared to a team of engineers waiting two weeks for a decision about how a business rule should behave, and that wait is the single most common source of overrun on projects that go over.
The fix is naming one person on your side who can decide without convening a committee, and giving them a target of answering within a working day. It costs nothing and it routinely saves more than any negotiation on rate.
The second cheapest is cutting the first release. Almost every project has a version that is 40% of the scope and delivers 80% of the value, and finding it before the contract is signed is worth more than any discount.
Six questions that change a quote
Ask these before accepting any estimate, of any partner. Each one moves the number materially, and a partner who cannot answer them has not scoped the work: which integrations are assumed to have working APIs; what happens to the estimate if one does not; whether data migration is inside or outside the figure; how exceptions discovered mid-build are handled commercially; what the estimate assumes about your response time; and what specifically is excluded.
The last one is the most revealing. An estimate with no exclusions list has not been thought about, because every real estimate has boundaries somebody chose.
Common questions
- What drives the cost of custom software development?
- Integrations first, then data migration, then edge cases the business handles manually today, then time lost waiting for client decisions, then compliance requirements. The number of screens, which is what most feature lists describe, barely moves the total.
- Why do custom software quotes vary so much between vendors?
- Because they are pricing different assumptions, usually about integrations and data migration. Two quotes for the same brief can differ by a factor of three when one assumes working APIs and the other has checked. Comparing quotes without comparing their exclusion lists compares nothing.
- How can we reduce the cost of a custom software project?
- Name one person who can answer questions within a working day, and cut the first release to the 40% of scope that delivers most of the value. Both cost nothing and both save more than negotiating the hourly rate.
- Should data migration be included in a software development quote?
- It should be explicitly in or explicitly out, and you should know which. Migration is routinely one of the largest blocks of effort, so a quote that does not mention it is either hiding a large number or has not looked at your data.
- How do you estimate a project before knowing everything?
- By producing a range and naming its assumptions, then narrowing it during a discovery stage that examines the integrations and the data. A single figure quoted before that examination is a guess presented as a commitment.
- What should an estimate exclude?
- Whatever has not been examined — typically undocumented integrations, data older than the current process, and exceptions nobody has written down. The presence of an exclusions list is the signal that the estimate was thought about; its absence is the warning.
Get a real number instead of a range
The discovery stage exists to turn the assumptions above into measured facts about your integrations, your data and your exceptions. It runs two to eight weeks and produces a plan you own, whoever builds it.
Start a conversationRelated guides
- Nearshore vs offshore software development
Overlapping hours, real cost after coordination, IP jurisdiction and travel, compared dimension by dimension — including when offshore is the better call.
- How to choose a software development partner
Twelve questions to ask before signing, what a good answer sounds like, and the four answers that should end the conversation.
- Custom software vs off-the-shelf
A decision frame by time horizon and total cost of ownership, plus the signals that say you chose wrong and it is time to switch back.