# What is behind a software project estimate?

> Look beyond the screen count. Compare the workflows, integrations, migration, and ongoing responsibilities included in a proposal.

- Published: Sep 25, 2026
- Topic: Project planning
- Author: RDR Digital
- Original: https://rdr.digital/blog/what-drives-software-project-cost

“We need a portal with five pages” sounds specific. It leaves several important questions open. Who uses the portal? What can each person see? Where does its information come from? What happens when an approval is rejected?

A page count is a useful inventory of screens. For comparing proposals, pair it with a description of the work those screens must support. This guide offers questions to ask; it does not give a universal price or promise a delivery timetable.

## Start with the problem and the boundary

Write down the problem in terms of the people doing the work. For example: “Our team re-enters approved orders into another system” gives a proposal something concrete to address.

Then define the first release. What must work at launch, and what can wait? Which systems remain in place? Which team supplies the content and makes operational decisions?

The [GOV.UK discovery guidance](https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works) emphasizes understanding users, constraints, and the problem before committing to a build. That principle is useful outside government too. It can reveal a simpler change or an existing product worth testing before commissioning software.

## Ask what sits behind each screen

Take one feature from a proposal and walk through it. An approval screen might require roles, permission rules, notifications, a record of decisions, and handling for an absent approver. Whether each item is necessary depends on your workflow.

Ask the supplier to explain the assumptions they used. A clearly excluded feature is easier to discuss than one both sides silently interpret differently.

A useful requirements conversation includes the following questions:

- Who is allowed to start, edit, approve, or cancel the task?
- What information is needed, and where does it come from?
- Which rules are fixed, and which should staff be able to configure?
- What should happen when the information is missing or incorrect?
- How will we demonstrate that the feature works?

## Compare the whole delivery scope

Use a shared comparison sheet. It does not need to be elaborate; its purpose is to expose differences that a total price hides.

| Area                 | Ask each supplier to clarify                                               |
| -------------------- | -------------------------------------------------------------------------- |
| Discovery and design | Which workflows, prototypes, and decisions are included?                   |
| Integrations         | Which systems and actions are covered, and what access is assumed?         |
| Data migration       | Who maps, cleans, transfers, and checks the records?                       |
| Quality checks       | Which devices, accessibility needs, and failure scenarios will be checked? |
| Launch               | Who handles deployment, training, and the operational handover?            |
| Ongoing operation    | Which hosting, support, maintenance, and external services are included?   |

Use the same expected outcomes when comparing proposals. If one includes a migration rehearsal and another assumes the client supplies clean import files, that is a difference in scope worth resolving before comparing the totals.

## Make uncertainty visible

Some questions cannot be answered confidently from a brief alone. An existing system may need investigation to establish whether it exposes the required data. A legacy export may need inspection before the mapping effort is understood.

Ask for those assumptions to be written down, along with the effect if they prove wrong. A proposal can separate known work from an investigation, rather than disguising an unknown as a precise commitment.

For a difficult integration, a limited proof of concept might be a sensible next step. Define the question it must answer and what evidence will end the investigation. The goal is a better decision, not an open-ended preliminary project.

## Agree how changes will be handled

During delivery, priorities may change. Decide how new requests are evaluated, who approves them, and how their effect on scope and timing is recorded. Ask how the team will distinguish a defect against agreed behaviour from a newly requested behaviour.

Keep acceptance criteria understandable to the people who will use the software. “An authorised manager can approve this request, and an unauthorised user cannot” is more useful to a review conversation than “permissions implemented.”

## Include the first day after launch

Name the owner for incidents, access changes, backups, updates, and questions from staff. Establish which responsibilities belong to your team, the supplier, and any platform vendors. Confirm the actual support arrangements rather than inferring them from the word “maintenance.”

A good proposal makes a decision easier because it explains the work. If you are still deciding whether a custom build is justified, start with our [build-or-buy guide](https://rdr.digital/blog/custom-software-or-saas). If migration is part of the scope, use the [migration planning checklist](https://rdr.digital/blog/planning-a-data-migration) to prepare your questions.

## Sources

- [GOV.UK Service Manual: How the discovery phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works)