What Custom Software Costs, and What Actually Drives the Number

We are not going to publish a price list, and you should be wary of anyone who does. A figure that has not met your requirements is a marketing number, and its purpose is to start a conversation rather than to be accurate. What we can do is explain what moves the number, so you can read the quotes you receive and tell the difference between a cheap one and an incomplete one.

Why the same brief gets wildly different quotes

Three reasons, and only one of them is about rates.

The first is scope interpretation. 'A CRM for our sales team' can be a lead list with reminders, or a system with quotation generation, approval workflow, telephony integration and territory-based reporting. Both are honest readings. The quotes differ by a factor of ten.

The second is what the price includes. Some quotes cover the build alone. Others include discovery, data migration, the parallel run, training, deployment, a support period and the fixes that follow first contact with real users. The second is usually the larger number and almost always the smaller total, because the excluded work still has to happen.

The third is rate, and it matters least of the three. A team at half the rate that takes three times as long is not cheaper, and a build that has to be redone is not cheaper at any rate.

The seven things that move the number most

1. The number of distinct user rolesEach role is a separate set of screens, permissions and tests. A system with one role is a fraction of the same system with five, even when the underlying data is identical. This is usually the single biggest driver and is almost always underestimated in the brief.
2. Integrations, and who controls themAn integration with a documented modern API is predictable work. An integration with a legacy system, an undocumented database, a vendor who must be scheduled, or a portal with no API at all is the least predictable work in the project. Two integrations of the same name can differ tenfold.
3. Data migrationMigrating clean data from one system is routine. Migrating a decade of spreadsheets with inconsistent codes, duplicate parties and exceptions nobody remembers is an archaeology project. The work is in the exceptions, and nobody knows how many there are until someone looks.
4. Offline and mobile requirements'It should also work on phones' can mean a responsive layout, which is nearly free, or an offline-capable app with a sync conflict model, which is a project of its own. These get written in the same sentence and priced very differently.
5. Compliance and audit requirementsStatutory reporting, audit trails, data residency, retention rules and access logging are real engineering, not paperwork. They also constrain the architecture, which means they cost much more when discovered late than when known at the start.
6. How much the requirements will changeNot a flaw - a property. If the domain is well understood and stable, a fixed scope is achievable. If you are building something genuinely new, the scope will move, and a fixed-price contract will either be padded to cover that or will produce a fight. Both are worse than being honest about it upfront.
7. Performance and scale, if genuinely requiredMost business systems have modest load and should not be engineered as though they do not. But if you need real concurrency, large data volumes or strict response times, that is architecture, infrastructure and testing - and it needs to be known before the first design decision.

What does not move the number as much as people expect

The number of screens. Screens are the visible part and therefore the part briefs enumerate, but a well-structured application shares most of its machinery between them. Twenty screens over one clean data model costs far less than eight screens over four systems that disagree.

Visual design, within reason. A considered, consistent interface built on a design system is not the expensive part. A bespoke visual identity with custom illustration and motion can be, but that is a separate decision you can make independently.

The choice of mainstream technology. Arguments about frameworks rarely change the total. What changes the total is whether the people building it know the stack well and whether whoever maintains it afterwards can too.

How to get an estimate you can rely on

• Bring the real artefacts, not a description. Your actual rate card, a real invoice, a live spreadsheet, the report your manager asks for every Monday. Twenty minutes with real documents beats an hour of describing them.
• Name the three things that must be true for the project to be worth doing. These are your requirements. Everything else in the brief is negotiable, and knowing which is which lets a quote be scoped rather than padded.
• Ask what the quote excludes. The answer tells you more than the number. Migration, training, the parallel run and the post-launch fix period are the usual omissions.
• Ask for it phased, with something in production early. A phased plan surfaces the estimating errors while they are still small - and gives you the option to stop.
• Ask what the riskiest assumption is. Anyone who has actually estimated the work can answer immediately. Anyone who says there is no risk has not looked.

Fixed price, time and materials, or capped

Fixed price suits well-understood scope and transfers risk to the supplier, who prices that risk in. It works, and the cost is that changes become contractual events - which makes everyone defensive at exactly the point the project needs flexibility.

Time and materials suits exploratory work and is the honest model when scope will move, but it requires trust and gives you no ceiling unless you impose one.

A capped model per phase is usually the best of it: a firm number for a phase whose scope is genuinely understood, re-estimated at each phase boundary with what was learned. You get predictability where predictability is possible and flexibility where it is not.

The cheapest expensive mistake

Choosing on price alone and rebuilding in eighteen months. This is common enough to be the default outcome for first-time buyers. The warning signs are consistent: a quote well below the others with no explanation of why, no discovery before the number, no questions about your data, and a delivery date that assumes nothing will be learned during the build.

A quote that is lower because the supplier understands the domain and has built something similar is a genuinely better price. A quote that is lower because it omits migration, testing and the parallel run is the same price, paid later, in a worse order.