Custom software is priced by the work required to build it, not by the number of screens. The variables that move the figure most are the number of integrations, whether those systems have usable APIs, the compliance controls you have to meet, and how much of the process is already written down. Screen count barely registers.
That is why two projects that look similar in a demo can differ by a factor of four.
Where the money actually goes
In a typical engagement, the split looks roughly like this:
| Area | Share of effort | What drives it |
|---|---|---|
| Integrations | Often the largest | Systems without APIs, undocumented data models, rate limits, vendors who change things without notice |
| Business logic | Large | Rules, exceptions, approvals — the parts nobody wrote down |
| Interface | Moderate | Screen count matters here, and only here |
| Data modelling | Moderate | Getting this wrong is the most expensive mistake available |
| Testing and hardening | Moderate | Load, security, error paths, restores |
| Deployment and monitoring | Small but non-optional | Pipelines, alerting, rollback |
Clients consistently expect the interface to dominate. It rarely does.
The variables that move the number
Integration count, and whether APIs exist. Connecting to a system with good documentation is routine. Connecting to one that offers only a nightly CSV drop, or a database you are allowed to read but not write, is several times the work and carries ongoing fragility.
Compliance requirements. Audit logging, data residency, retention, access review and encryption are engineering work, not a checkbox. If your auditors require them, they belong in the estimate from the start.
How well the process is understood. If you can describe the workflow step by step including the exceptions, scoping is fast. If the answer is "ask Maria, she knows," discovery is real work and pretending otherwise just moves the cost later.
AI, if any. Inference is a per-use running cost rather than a fixed one, so it scales with volume. Building it responsibly also means an evaluation set and a human review path, which are part of the build.
Who maintains it. Software that your team will own needs documentation and handover. Software we continue to run needs monitoring and an on-call arrangement. Both are real, and they are different.
Why we do not publish a rate card
Because a band published without knowing the work misleads in both directions. It makes simple projects look expensive and complex ones look cheap, and the client who most needs an accurate figure is the one most misled by an average.
What we do instead is scope first. A scoping conversation produces a written description of what the first release must do, what it deliberately will not do, and the integrations involved. The estimate follows from that document, and so does the ability to hold us to it.
How to get an estimate you can rely on
Bring these four things to the conversation and any competent firm can give you a defensible number:
- The process, written down, including what happens when it goes wrong
- The systems it must talk to, and whether each has an API
- The compliance controls you are held to
- Who will own it after launch
If a supplier quotes confidently without asking for those, the number is a guess. It may still be a low guess — that is usually worse, because the difference surfaces as change requests once you are committed.
The cost most estimates leave out
The workarounds you are paying for today. Spreadsheets maintained beside the system, staff re-keying data between tools, a report someone rebuilds by hand every Monday. None of it appears on a budget line and all of it is real spend.
We ask clients to count it before deciding: how many hours a week, at what cost, across how many people. Frequently that figure is larger than the software, which changes the question from what does this cost to what is not building it already costing.
- pricing
- scoping
- custom-software
- procurement