What does custom software cost? Compare scope, uncertainty and operation

An estimate starts with a bounded workflow

Ask which task the first release supports from beginning to end. A portal accepting documents differs from a portal assessing changes, confirming arrangements and correcting invoices. Both proposals might show a single home screen while involving different decisions and controls. Describe a normal task and an important exception before placing their prices next to each other in a comparison.

A fictional consultancy wants customers to supplement information. In one version they upload documents for staff review. In another, the system extracts information, compares it with existing records and suggests changes. The second design requires different investigation, testing and operational work. Without acknowledging those differences, the cheapest proposal may simply describe a smaller assignment rather than a more efficient delivery of the same outcome.

GOV.UK Service Manual: How the discovery phase works ↗

Make the cost structure understandable

Divide the estimate into meaningful results: process investigation, design, technical foundations, data transfer, user operations, testing and introduction. This need not become a timesheet listing every tiny activity. You should still recognise which work removes the main uncertainty and which work produces a demonstrable capability or operational procedure. Ask for clarification where the output of a proposed item remains unclear.

Examine expenditure outside development too, including licences, hosting, external service use, internal preparation and staff instruction. Investigate whether recurring costs are included or billed separately. A plausible build amount says little about the complete working arrangement if data cleanup, obtaining access and daily review are omitted from the comparison. Make ownership of those activities explicit rather than leaving them as an unspecified customer responsibility.

Treat uncertain dependencies as investigation

An existing database, restricted API or unknown product rule can materially affect an estimate. Name the uncertainty: can a request with attachments be retrieved, is a stable identifier available, or can organisation-specific permissions be enforced? A focused feasibility test can answer that question. Agree beforehand what the investigation should demonstrate and who provides the information needed to perform it.

Hiding uncertainty inside a broad contingency makes the budget harder to discuss. State which implementation can already be estimated and which decision follows discovery. For the consultancy, an experiment might reveal that historical attachments are unavailable through the proposed export. Scope can then change before a broad migration promise becomes part of the implementation assignment. A bounded discovery result helps avoid paying for a design based on an unconfirmed dependency.

A budget should cover access, documentation and the ability to continue with another developer later: Deliver new software: arrange code, accounts, data and future development.

Why exceptions alter project size

The ordinary path rarely represents all the work. A customer might replace a document while someone reviews it. An external service may save a change without returning confirmation. A user may belong to several organisations. These situations affect data structures, access, failure handling and trial cases even when very few additional screens are needed. Their cost follows behaviour, not their visibility in the interface.

Identify exceptions that matter to your organisation and decide which belong in the first release. Others might temporarily use an agreed manual route. That can limit initial investment if someone can perform the work and later reconciliation remains possible. An explicit limitation is easier to estimate than a general expectation that every existing situation will automatically be handled without further discussion or operational effort.

Build a comparison with your own inputs

Create a table separating one-time work, recurring expenditure and internal effort. Use offered amounts and state the period, volume and included activity. One variant may need less development but more staff review. Another may automate further while requiring more testing and maintenance. Either can be appropriate; the outcome depends on actual usage and the responsibility the organisation chooses to accept.

A fictional calculation structure makes the difference visible: first-year expenditure consists of agreed introduction work plus twelve months of recurring usage, supplemented by separately estimated internal work. Replace every input with your own information. Check that a service is not counted both inside a subscription and as a separate charge. Keep amounts, units of time and capacity value distinct so others can understand and challenge the calculation.

Examine value without promising a saving

Measure the current process and identify which part the proposed version may change. Include searching, review, recovery and exception handling. Less typing can free capacity without reducing salaries or external invoices. First explain what time may become available and which concrete activity the organisation would support with it. That is a different claim from saying the same amount will disappear from expenditure.

After a pilot, compare the same task definition and period. A new application may initially need more instruction or reveal previously hidden problems. Assess completeness, understandable progress and recovery work alongside speed. Choose a few measurable indicators with objectives of your own. Google SRE’s distinction between indicators and objectives helps assess outcomes without converting every operational improvement immediately into a monetary claim.

Google SRE: Service Level Objectives ↗

Connect phases with decisions and usable outputs

A phased assignment is useful when a completed step enables a real decision. Discovery might establish access and a data agreement. An initial application might support one complete customer task. A pilot might provide evidence about daily use and exceptions. For each phase, ask what becomes available and which information is needed to assess another investment rather than treating phases as development labels alone.

Avoid phasing that is merely a payment schedule while uncertainty accumulates until the end. The consultancy could first test document supplementation with a bounded customer group, then investigate automatic processing. Record how the existing workflow continues meanwhile. A small release must remain workable: unfinished handovers can otherwise create more operational effort than the budget acknowledges, making the first phase cheaper on paper but difficult to use.

Include maintenance and change

Software remains dependent on services, libraries, accounts and business rules. Discuss who handles alerts, reviews updates and checks modifications. Distinguish agreed maintenance, correction of a defect and new capabilities. Those boundaries determine which recurring activity is covered and which decisions return to the customer. A maintenance label alone cannot explain all the obligations and exclusions in a proposed working relationship.

Ask how another developer could make a small change. Available source, build instructions and trial cases affect the transferability of future work. A low initial price can become less attractive if every modification begins by reconstructing the system. This does not require elaborate documentation of everything; it requires the key decisions, dependencies and operational activities to be understandable enough for the agreed team and scope.

Compare proposals using the same open questions

For each proposal, ask which assumptions were used, which activities are excluded and which dependencies remain unconfirmed. Place a normal task, two exceptions and the intended first introduction alongside the proposed delivery. A supplier should explain how the proposal addresses them and where an alternative or narrower beginning may be more proportionate to the available evidence and current business problem.

Finish the budget with selected scope, an owner of substantive decisions and a route for change. A project can learn and evolve without making its commercial arrangements unintelligible. The essential point is that new work is explicitly assessed through its consequences. Price then belongs to an understandable assignment instead of becoming an isolated number used to rank solutions that actually deliver different things.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• Custom software development ↗
• Customer portal development ↗

Questions about this topic

Continue with a related question