The most costly factors of custom software development are, in our judgement and roughly in this order: a scope that is not settled, the number of tasks and screens the system has, business rules that nobody has written down, existing data that has to be brought across, and connections to other systems. Writing the code is a smaller share of the cost than most buyers expect. The larger share is working out exactly what the software should do, and proving that it does it.
This article explains why each factor costs what it does, how to measure it for your own project and what you can do to reduce it. It contains no prices. For figures, our answer on how much bespoke software costs and our cost calculator give ranges.
An unsettled scope
Work that changes direction after it has started is paid for twice: once to build the first version and again to alter it. A change to how the data is organised is the most expensive kind, because every screen and report built on top of it has to follow.
Waiting costs money as well. A team that cannot proceed until someone decides how refunds should work still has to be paid for, by you under time and materials or by the supplier under a fixed price, and either way the project slows.
Tools that help developers write code faster have reduced the cost of producing software once it is clear what is wanted. They have not reduced the cost of deciding what is wanted, so in proportion an unsettled scope matters more than it used to.
How to reduce it. Agree in writing what the system will do, what it will not do and how you will judge that it is finished, before the build starts. Name one person who can make decisions. Decide what the first version must do and move everything else to a later phase.
The number of tasks, screens and reports
Size is the most predictable factor. Every screen and report has to be designed, built, tested and explained to the people who use it, so the cost rises broadly in step with the count. A system that handles one process for one team is a different job from one that runs a whole operation.
Two things multiply size without being obvious.
A second platform. A web application that also works in a phone’s browser is one thing to build. A separate app installed from the app stores is a second, with its own testing and its own updates. Our article on native apps and web apps explains when the installed app is worth it.
Reports. Buyers often list screens and forget reports. Each report is a piece of work in its own right, and the ones that combine data from several places are among the harder parts of a system.
How to reduce it. Count the screens and reports people use every week, and ask who would miss each of the others. In an existing system, some usually turn out to be used by nobody.
Rules, exceptions and permissions
Two systems with the same number of screens can differ widely in cost, because of what happens behind the screens.
Business rules. Pricing that depends on the customer, the quantity and the date. Approval steps that vary with the amount. Stock that can be reserved but not yet picked. Each rule has to be discovered, agreed, built and tested, and every exception to it needs testing too. The rules that cost most are the ones that live in people’s heads or in spreadsheet formulas, because they have to be found before they can be built.
Permissions. If everyone can see and do everything, permissions cost almost nothing. Once a manager can approve what a team member cannot, or a customer may see only their own records, every screen has to enforce the rule and every combination has to be tested.
Requirements for security, audit and availability. A system that takes card payments, holds sensitive personal data, must record who changed what, or has to be available around the clock carries extra design and testing work. Where these arise from regulation, take advice on what your obligations are before the scope is written.
How to reduce it. Write the rules down, with examples, before you ask for a quote. Then ask of each exception whether it is still needed. Some exist only because the old system could not do it any other way.
Existing data and connections to other systems
These two are the factors buyers most often leave out, and the ones most likely to surprise a supplier that did not look before quoting.
Existing data. A system that starts empty is the cheapest case. Bringing across years of records means working out how the old structure maps to the new one, cleaning what is wrong and rehearsing the move until the figures agree. Duplicates, missing links between records and free-text fields used for several purposes all add time. The amount of data matters less than its condition.
Connections. Each link to another system, such as an accounting package, a payment provider or a supplier’s ordering system, is a small project of its own. The cost depends chiefly on the other system. One with a documented API, a published way for programs to exchange data, is far simpler to connect to than one that offers only file exports or nothing at all. Each link also needs an agreed answer to what happens when the other system is unavailable.
How to reduce it. Let the supplier see a sample of the real data before it quotes. Clean the data yourself where you can, since nobody knows it better. Bring across only the history you need. For each connection, find out whether the other system has an API and who can grant access to it.
What costs less than people expect
The number of users. For an internal business system, the difference between ten users and a hundred has little effect on the build. It affects hosting and, more than anything, the number of people to train.
How it looks. Clean, consistent screens made from standard components cost little. A visual design of your own, with custom illustration and animation, adds work and is usually worth paying for only where customers will see it. Ease of use is a different matter: time spent watching how people do the job pays for itself in fewer mistakes, and is not the place to save.
A single extra field. Small additions to something already planned are cheap if they are raised before it is built. The same request after the screen is finished and tested costs considerably more, which is one more reason to settle the scope early.
The cost that people underestimate is the one that comes after the build. Hosting, security updates, fixes and small changes continue for as long as the system is in use, so ask for them to be quoted at the same time as the build.
What to count before you ask for a quote
A supplier can only price what it can see. The table below lists what to gather for each factor. Our project planning worksheet has space for all of it.
| Factor | What to count or check |
|---|---|
| Scope | The five things the system must do on day one, and what can wait |
| Size | Screens and reports in weekly use, and whether an installed mobile app is needed |
| Rules | Pricing, approval and exception rules, each with an example |
| Permissions | The types of user, and what each may see and do |
| Data | Where the records are now, roughly how many, and who can vouch for their accuracy |
| Connections | Each other system, which way the data flows, and whether it has an API |
| After launch | Who will host and maintain the system, and for how long you expect to use it |
Send the same list to every supplier you approach. Quotes written against the same facts can be compared, and a supplier that asks to see the data and the rules before naming a figure is showing you how it will run the project.