Ask what custom software costs and you will get a range so wide it is useless: $50,000 to $5 million. That range is real, but it is not an answer. The number depends on what the software has to survive: how many systems it touches, how much history has to come with it, and how badly things break if it is down for an afternoon. This page breaks the cost into the parts that actually vary.
The three cost tiers
Nearly every engagement falls into one of three shapes. Knowing which one you are in is more useful than any hourly rate.
| Shape | Typical range | Duration | What you get |
|---|---|---|---|
| Focused assessment | $15,000 – $40,000 | 2–5 weeks | Mapped workflows, system and data inventory, a costed delivery sequence, and a build-or-buy recommendation you can act on. |
| Bounded first release | $40,000 – $120,000 | 6–14 weeks | One valuable workflow running in production with real users, real data, and a path to expand. |
| Platform or core system | $250,000 – $1.5M+ | 6–24 months, phased | A system that replaces or absorbs a business-critical platform, delivered in releases that each stand on their own. |
What actually drives the number
Clients tend to estimate cost by counting screens. Screens are the cheap part. The expensive parts are usually invisible in a wireframe.
Integrations
Every system you must talk to adds cost, and the cost is not linear. A documented REST API with a sandbox might be a week. An undocumented SOAP endpoint on a system whose vendor no longer employs anyone who built it can consume a month before a single record moves. The question to ask is not how many integrations, but how many of them you control.
Data migration
This is the single most reliable source of overrun. Twenty years of operational data contains duplicate customers, orphaned records, dates stored as text, and business rules that exist only as conventions someone enforced by hand. Migration cost tracks data quality, not data volume. A clean million-row table is cheaper than a filthy ten-thousand-row one.
Permissions and multi-entity structure
If different locations, franchises, or business units must see different slices of the same data, that requirement reaches into every query, every screen, and every test in the system. It is one of the few requirements that genuinely multiplies cost, and it is almost never mentioned in an initial brief.
Operational risk tolerance
Software that can be wrong for an hour is much cheaper than software that cannot. Payroll, dispatch, invoicing, and compliance workflows carry costs for reconciliation, audit trails, monitoring, and rollback that a internal reporting tool simply does not.
- Number of systems that must stay in sync, and who owns each one
- Age and quality of the data that has to come across
- Whether users are internal, external, or both
- Regulatory or audit obligations attached to the workflow
- Whether the legacy system must keep running during the transition
- How much institutional knowledge exists only in people's heads
Why fixed bids before discovery cost more
A fixed price quoted before anyone has mapped the workflow is not a commitment; it is a bet. The vendor has priced their worst-case assumption plus a risk premium, or they have priced optimistically and intend to recover the difference through change orders. Both are more expensive than scoping the work first.
The alternative is not open-ended time and materials. It is a small, fixed, defined first step (an assessment or a bounded release), after which the next increment is priced against something real. You approve a known next step rather than an open commitment, and a mismatch surfaces as a decision point instead of a surprise at the end.
The comparison that matters: five-year cost
Custom software is usually evaluated against a build-vs-buy comparison that quietly omits half the cost of buying. Licensing is only the visible part. Per-seat pricing that discourages you from giving field staff access, mandatory implementation partners, paid connectors, version upgrades, and the labor cost of the manual workarounds people invent to route around a bad fit all belong in the comparison.
| Cost line | Keep the platform | Replace it |
|---|---|---|
| Licensing / subscription | $480,000 | $0 |
| Implementation & customization | $150,000 | $420,000 |
| Hosting & infrastructure | Included | $90,000 |
| Ongoing support & change | $120,000 | $200,000 |
| Manual workaround labor | $300,000 | $40,000 |
| Five-year total | $1,050,000 | $750,000 |
A trades services business facing a six-figure ERP renewal moved core dispatch, field updates, and invoicing onto a bridge stack in six weeks, avoiding roughly $100,000 in renewal cost while the real platform was designed around how the work actually ran.
Where budgets actually break
Overruns are rarely caused by the work being harder than expected. They are caused by work that was never in the estimate because nobody thought to name it. These are the lines that go missing most often.
The decision bottleneck
The most expensive delay in most projects is waiting for someone internal to decide something. A team of four sitting idle for three weeks because a pricing rule needs an owner's ruling is a real cost, and it appears on the invoice as delivery time. Before work starts, name the person who can settle domain questions within two business days and confirm they have the capacity to do it.
The last ten percent
Getting a workflow demonstrably working is roughly two-thirds of the effort. The remaining third is error states, permissions, edge cases, data backfill, training, and the small changes users ask for once they touch it. Estimates that stop at the happy path are short by about half.
Parallel running
If the old system must stay live during transition, you are paying for both systems and for the people reconciling them. That period is often the single largest unplanned line item in a replacement project, and its length is a decision rather than a fact. Set an exit condition for it at the start.
- Data cleansing labor on your side, which is usually yours to do and rarely scheduled
- User acceptance testing time from people who already have full-time jobs
- Training, documentation, and the productivity dip in the first month after cutover
- Third-party costs: API tiers, connector licences, sandbox environments, security review
- Ongoing hosting, monitoring, and dependency maintenance from the day you go live
How to get a number you can trust
- 1
Bring your budget range to the first conversation. It is not a negotiating position. It is the fastest way to hear honestly whether the outcome is achievable.
- 2
Ask what the first 60 days produce. If the answer is documentation only, keep asking.
- 3
Ask which assumption, if wrong, breaks the estimate. A serious partner names it immediately.
- 4
Ask how data migration is priced. Vague answers here predict overruns better than any other signal.
- 5
Ask what you own and what happens if you stop. Ownership, documentation, and exit terms should be in the agreement, not the sales conversation.
Common questions
- Is custom software cheaper than an off-the-shelf platform?
- Not at the start, and often not in year one. It becomes cheaper when per-seat licensing, mandatory implementation partners, paid connectors, and the labor cost of manual workarounds are counted over four to five years, and when the platform's constraints are actively costing you throughput. If an off-the-shelf system fits your operation well, keep it.
- What is the minimum realistic budget to start?
- A focused assessment starts around $15,000 and produces a mapped workflow, a costed sequence, and a build-or-buy recommendation. A bounded first release that puts one workflow into production with real users generally starts around $40,000. Below that, you are buying a prototype, which is a legitimate purchase but a different one.
- Why do estimates vary so much between vendors?
- Usually because they are pricing different scopes and neither has said so. One may assume you handle data migration and user acceptance testing; another may include them. Ask every vendor to state explicitly what is excluded. The differences almost always live there rather than in the hourly rate.
- How much should we budget for ongoing costs after launch?
- Plan on 15–25% of build cost per year for hosting, monitoring, dependency updates, and change. Software that is actually used generates change requests; a system with no ongoing spend is usually a system no one depends on.
- Does offshore development meaningfully reduce cost?
- Hourly rates drop; total cost often does not, because the expensive parts of this work are domain understanding and decision-making rather than typing. Distributed delivery works well when the domain is well understood and the specification is genuinely stable. It works poorly for discovery-heavy operational software where the requirements are being uncovered as you go.