The honest answer to 'what does custom software cost?' is that it depends far less on features than on how much uncertainty sits inside them. A quote is really a price on unknowns.
For a small or mid-sized business, a first useful piece of custom software is usually a single workflow, not a system. That distinction is what separates a project that pays back inside a year from one that never quite finishes.
The four things that actually move the number
Almost every estimate we have written moves on these four, in roughly this order of impact.
- Decision complexity — how many rules, exceptions and judgement calls the software has to reproduce. Ten pricing exceptions cost more than a hundred screens.
- Integration surface — how many other systems it must read from or write to, and how well those systems are documented. Undocumented legacy is the single biggest multiplier.
- Data quality — if two systems disagree today, somebody has to decide who wins. That decision is analysis work, not coding work.
- Compliance and access — audit trails, roles, retention rules and approvals are cheap to build early and expensive to retrofit.
What a first workflow looks like
A well-scoped first build does one thing that a person currently does manually, every day, with consequences when it goes wrong: the exception queue, the quote calculation, the job scheduling board, the compliance pack.
It has a measurable before and after — hours per week, error rate, days to invoice — and it runs in production rather than in a demo environment. If a proposal cannot state the measure, it is not scoped yet.
Deliberately out of scope in a first build: a redesign of anything that already works, a data warehouse, a mobile app nobody asked for, and any feature justified only by 'we'll need it eventually'.
When licences are simply cheaper
Custom is the wrong answer for commodity work. Payroll, email, accounting ledgers, e-signature, video calls, helpdesk basics: these are solved, regulated and cheap. Renting them is the correct financial decision, and building them is a mistake we will argue you out of.
The test is not 'could we build it?' but 'does doing this differently win us anything?' If the answer is no, rent it and move on. If a workflow is the reason customers choose you, or the reason your margin is better than a competitor's, that is where ownership earns its cost.
The cost most estimates leave out
Two ongoing costs matter more than the build fee. The first is maintenance: expect a modest annual percentage of the original build to keep dependencies current and handle change. The second is the cost of not building — the salary hours spent reconciling, re-keying and chasing, which usually never appear on any invoice.
Put both in the same table before you decide. A workflow consuming twelve hours a week of skilled time is already an expensive piece of software; it is just being paid for in payroll.
How to get a number you can trust
Ask for the estimate to be broken down by workflow, not by technology. Ask which assumptions would change it by more than twenty percent. Ask what happens to the code and the accounts if the relationship ends — the answer should be that you already own both.
And ask for the smallest version that produces a measurable result. If a supplier cannot describe one, the risk is not in the price.