Why custom software quotes vary so wildly, and what actually drives the cost
Three quotes for the same tool, none of them alike. Integrations, user types, data migration and brief clarity — how to read a quote properly.
Three quotes, one job, three different numbers
You asked a few different people to quote the same piece of software. You described it the same way each time, sent the same brief, answered the same questions. The numbers that came back had nothing in common with each other. That is not a sign someone is trying it on. It is a sign that “the same job” was never as clearly defined as it felt, and each business filled in the blanks differently.
Once you understand what genuinely drives the cost of a custom tool, a quote stops being a mystery figure and becomes something you can actually read.
How many kinds of user are you really building for
A tool with one type of user — say, just your staff, all doing roughly the same thing — is comparatively simple. Add a second type of user with different needs and you are not adding a feature. You are effectively building a second product that happens to share a database with the first.
Staff, a manager who needs oversight and reporting, and a customer-facing portal is three products, not one tool with extra bits bolted on. Each user type needs its own screens, its own logic for what it is allowed to do, and its own testing. A quote that has clearly counted your user types will usually explain, unprompted, how it has separated them. One that hasn’t distinguished them at all is a warning sign, not a bargain.
Integrations are the single biggest multiplier
Nothing moves a quote more than what the new tool has to talk to. If it only needs to talk to modern, well-documented systems with a genuine interface built for connecting software together, that work is routine and predictable. The documentation exists, and the behaviour is consistent.
The trouble starts when the new tool needs to talk to something older: a desktop accounting package that was never built to be connected to anything, a system with no real way in at all, or a supplier’s software that only exports awkward files. Every one of those can multiply the effort involved, because instead of following documentation the developer is reverse-engineering behaviour and testing against something that might change without warning.
If your business runs on a mix of old and new systems, ask every quote, plainly, what it assumes about each integration. This is usually where the real gap between quotes is hiding.
Data migration is almost always underestimated
Moving to new software is the easy part. Moving the history — years of customer records, jobs, invoices, notes typed into free-text fields — is where things get expensive. Real business data is inconsistent. Names are spelled three different ways. A phone number was typed into the email field years ago. Two customers were entered twice and never merged.
A quote that assumes your data will arrive clean is a quote that has not looked at your data. Cleaning and migrating messy historical records can end up costing more than the software being built to hold it. If a quote treats migration as an afterthought, or a single line near the bottom, ask what it has actually assumed about the state your data is in.
Permissions and audit trails sound small. They are not
“Who can see what” and “who changed this, and when” feel like small technical details. They are not. Getting permissions right means thinking through every role and every combination of access — a casual staff member versus a manager, what a customer portal user should never reach, what happens when someone changes roles.
An audit trail — a record of who did what and when — adds its own layer of work, because every change now has to be logged, stored and made retrievable. Both are easy to skip when quoting and expensive to bolt on afterwards. A quote that has priced them in properly will usually look larger than one that hasn’t mentioned them at all.
Compliance and privacy change the shape of the job
If the tool touches health information, information about children, education records or financial information, the rules around storing, securing and handling that information add real weight to the build. This is not paperwork for its own sake. It affects how the system is structured from the ground up — how data is stored, who can export it, what gets logged. A quote for a tool handling sensitive information that reads identically to a quote for a simple internal rostering tool should make you ask questions.
Software also needs somewhere to run, and someone who notices when it breaks. Ask, directly, whether ongoing hosting, updates and support are included in the quote, or a separate conversation for later. A quote that looks low because it only covers the build, with nothing said about what happens after launch, is not actually a low quote — it is an incomplete one.
The clearest brief gets the most comparable quotes
Of everything on this list, the brief is the one thing you control directly. A vague brief forces every developer to guess, and they will each guess differently — about user types, about integrations, about how messy your data really is. Those guesses are exactly why three quotes for “the same job” can look so different: they were never quoting the same job at all.
A clear brief spells out who will use the tool and what each needs to do, what other systems it connects to, roughly how much historical data exists and how messy it is, and any privacy or compliance requirements you already know about. The clearer the brief, the closer the quotes will land to each other.
Why custom is more affordable than it used to be
Custom software has genuinely become more affordable over the past few years. Many of the building blocks — logins, payments, hosting, basic interface components — no longer have to be built from scratch for every project. Less bespoke plumbing means less time spent on parts that used to eat budgets without adding anything the business could see or use. That is a real shift, not a sales line.
But cheap to build and cheap to own are different questions. A tool that was quick to put together can still be costly to run if nobody planned for support, updates, or the slow accumulation of small fixes every piece of software needs over time.
The cheapest quote is not usually the most efficient developer. More often, it is the one who has understood the least about your business, your data and what could go wrong, and has priced accordingly. A low number with no detail behind it is a question, not an answer.
Making quotes comparable
Before you compare numbers, put every quote through the same checklist: how many user types has it counted, what has it assumed about each integration and your data, has it priced in permissions and an audit trail, has it addressed compliance, and does it say who looks after the tool after launch. Ask each provider the same direct questions, and read what they leave out as carefully as what they include. That is how three unreadable numbers turn into three answers to the same question.