Custom software cost: what changes a business quote

Memo: agree what the price is buying

A quote headed “equipment inspection system” leaves plenty unsaid. Can an inspector finish a check without internet access? Can a supervisor correct a mistake after a check has closed? Does the supplier load the equipment list, or does your team prepare and enter it? Each answer changes the work being commissioned.

The GOV.UK purchasing strategy guidance recommends understanding the full cost and the product lifecycle, including improvement and retirement. It is public-sector guidance. For a private business, the useful buying habit is to examine what you will have to pay for and operate beyond the first release.

The comparison below is a hypothetical buying exercise, with no quoted prices. Its purpose is to expose differences that a shared project name can conceal. For the earlier decision about the type of solution, use the build, buy or connect comparison.

Two scopes for the same inspection task

Imagine a business that inspects its equipment and records faults. The agreed outcome is that an inspector records a check and a supervisor can see which faults remain open. The two scopes below belong to the same invented business; neither describes a Fulcrum client or an available package.

Scope A: connected workshop. Staff use a web application at one workshop with internet access. An administrator supplies an agreed equipment list. Inspectors record checks, supervisors close faults, and the business keeps older inspection files in its existing archive. The software starts recording new inspection history from launch. Offline working and photo attachments are excluded.

Scope B: field use with history. The same task must work at several sites, including places without a dependable connection. An inspector records checks and photos offline, then sends them when connected. Staff see the equipment assigned to their site; managers can review across sites. Historic checks and photographs must become searchable against the correct equipment record.

Both scopes need a definition of a completed check and a rule for correcting it. Scope B adds unanswered questions: what happens when two people change the same fault offline, and who confirms that an old photograph belongs to the right asset? Those are behaviours and preparation tasks that need agreement before a supplier can price them confidently.

If staff can complete the task online, choose that constraint explicitly. If work genuinely happens without a connection, include the offline case in acceptance. Similarly, importing every old record deserves a business reason. Keeping a usable archive may meet the need, provided the team agrees how it will find records there.

Read the assumptions behind the build

The following are quote-review prompts derived from the example. They are not a universal formula for estimating software.

Behaviour: ask which paths are included. “Record a check” should say whether a user can abandon it, amend it after submission or reopen a closed fault. A supplier assuming a single straight-through path has priced different work from one covering these exceptions.

Operating conditions: identify the devices, connection conditions and access rules the delivery must support. In Scope B, “works offline” still needs a boundary: which tasks work, how long records can remain on a device, and what the user sees when sending fails. Agree the required behaviour without prescribing the technical solution.

Data preparation: separate importing records from deciding what they mean. Microsoft’s Dataverse migration guidance calls out mapping and transformation, data quality and relationship dependencies. That guidance concerns migrations into Dataverse; it does not establish a price or method for every platform. In the example, use a sample of the actual files to establish who resolves duplicate asset names and missing references.

Acceptance and rollout: specify who checks the finished work, using which examples, and what staff need before they switch. Include the correction of a submitted check in the acceptance examples. Record whether training and loading the starting equipment list sit in the supplier’s scope or your own team’s workload.

Give running costs their own page

Ask each supplier to show recurring charges separately from delivery. The useful questions are what creates a charge, what usage the estimate assumes and who reviews the bill. For Scope B, ask how retained photographs and growing inspection history enter that estimate.

The AWS Well-Architected cost principles recommend matching resource consumption to need and attributing expenditure to workload owners. This is AWS guidance, not a promise that a particular hosting design will be cheaper. The practical request is an operating estimate with a named owner and visible usage assumptions.

List hosting and third-party subscriptions alongside the support arrangement. Ask whether monitoring, backups and recovery checks are included, how faults are reported, and how later changes are commissioned. Record any work your staff will do. A monthly hosting allowance tells you little about those responsibilities.

The ongoing software support service describes maintenance and monitoring as work to agree. Apply the same discipline when comparing proposals: write down the coverage and response arrangement each quote actually includes.

Copy this comparison sheet into the quote request

Send the same completed sheet to each supplier. Leave an unanswered item marked “unconfirmed”; an empty cell is too easy to read as someone else’s responsibility. Ask suppliers to record any different assumption next to the relevant line.

Use one entry per cost-driving assumption, with these fields: required result; included work; excluded work; evidence or volume basis; responsible person; charge basis; condition that would change the price. “Charge basis” can record a fixed allowance, a usage charge or separately agreed work, using the supplier’s actual terms.

For the hypothetical history import, an entry could read: Result: historic checks can be found by asset. Included: only the agreed files and fields. Excluded: reconstructing missing asset references. Basis: a reviewed sample and a confirmed file inventory. Owner: the business resolves ambiguous references. Charge basis: supplier to state. Change condition: additional files or unresolved mappings. This is an example of scope wording, not a migration specification.

Then keep a short decision record: which proposal covers the agreed result, which assumptions remain unresolved, and what your team would still need to deliver. Ask for a revised proposal where suppliers have priced different boundaries.

• ·Build comparison: required behaviours, supported devices, data work, acceptance and rollout.
• ·Operating comparison: recurring charges, usage assumptions, support coverage and business responsibilities.
• ·Change comparison: exclusions, allowance limits and the process for agreeing additional work.

Compare the scope before the total

Make the remaining uncertainty a decision

An unresolved assumption should lead to a specific next action. If the history import is unclear, review representative records and agree the boundary. If the team disagrees about offline use, follow an inspection where the connection fails. Keep the result in the comparison sheet so each supplier prices the same decision.

This memo offers a way to compare scope, not a UK market price benchmark. Sources were checked on 14 October 2026. The two scopes and the comparison worksheet are editorial examples; no fees, delivery times or savings are inferred from the documentation.