Two bespoke software proposals can quote very different prices while describing apparently similar screens. The difference may reflect the amount of discovery, the integration work, the testing approach or the support arrangement. It may also reflect assumptions that one supplier has explained and another has left unstated.
A useful comparison makes those differences visible before choosing a supplier. The business needs to understand what each proposal intends to deliver, what evidence will demonstrate success and what it will take to operate the application afterwards.
Price remains an important input. The aim is to compare it against an equivalent business outcome and an understood delivery arrangement. A higher price does not automatically establish better work, and a lower one does not prove that a supplier has missed something.
Give suppliers a common problem to respond to
Describe the work the business needs to improve, the people doing it and the current difficulties. Include examples of important tasks and their outcomes. A proposal for “a customer portal” can hide very different interpretations unless the underlying journeys are clear.
Supply relevant constraints such as existing systems, data sources, required roles and operating hours. Distinguish established requirements from ideas that need investigation. This helps suppliers state which parts of their estimate are supported and which rely on assumptions.
Understand the problem, users and constraints before committing to a build. Discovery can establish the evidence needed for a reliable commercial implementation scope. Confirm what remains uncertain and how it will be investigated. Our website discovery planning guide provides the related checks.
Ask every supplier to explain how its proposed work supports the same core outcomes. This does not require identical technical solutions. It creates a consistent basis for examining the differences that matter.
Compare complete workflows rather than feature names
Choose several representative journeys and trace what each proposal includes. For an order application, follow creation, validation, approval, fulfilment handover and reporting. Record the roles, information and connected systems involved at each step.
A feature called “approval” might mean a simple status button in one proposal and a role-based sequence with notifications and exception handling in another. Ask for the intended behaviour in ordinary language. A shared label is insufficient evidence of equivalent scope.
Inspect difficult cases such as amended requests, missing information and failed integrations. The proposal should explain whether these are included, need further investigation or remain manual. Ordinary exceptions can account for substantial delivery and operating work.
Use a comparison table in your working assessment with one workflow per row. Record the supplier's explanation, assumptions and unresolved questions. This keeps the discussion grounded in business tasks rather than the visual polish of the proposal.
Consider an illustrative equipment hire application where customers can amend a reservation after a deposit is recorded. One proposal may include the original reservation screen but leave amendments to staff; another may include revised availability checks and a reviewed payment adjustment process. Put that exact journey to both suppliers. Ask what the customer sees, what staff must do and which connected services are involved. If a manual step remains, record its owner and expected workload. This exposes a meaningful difference without assuming that automation is always preferable. The comparison can then explain whether the additional scope solves a real operating problem, rather than crediting a proposal simply for including a longer feature list.
Examine discovery and scope control
Ask what the supplier needs to learn before building and what the discovery output will be. Useful outputs might include tested workflow assumptions, a data model outline, integration findings and a prioritised release scope. The details should match the uncertainty in your project.
Clarify whether discovery changes the implementation estimate and how the business makes the next decision. A staged proposal can be sensible when unknowns are material, provided the outputs and decision points are clear. It should not leave the organisation unable to assess the value of the first stage.
Identify the minimum useful release and the capabilities proposed for later. Ask how the initial release will operate with existing systems and manual tasks. A small release is valuable when the business can use it coherently, rather than when it is merely a collection of completed screens.
Review the process for changing scope. Find out how new requests are assessed, how their effects on time and cost are explained and who can authorise them. A practical change process helps preserve a shared understanding as the team learns.
Inspect integration and data assumptions
List every external system the application will use and compare the proposed responsibility for connecting it. Ask whether the supplier has verified access, available interfaces and relevant limits. An integration estimate based on an assumed API can change significantly when the actual system is examined.
Check the data migration scope separately from ongoing integration. Moving historic records, preserving relationships and validating the result are different tasks from connecting future events. A proposal that mentions “CRM integration” may cover only one of them.
Ask how the application handles an unavailable dependency or an ambiguous response. The business needs a clear account of retries, duplicate prevention and cases requiring investigation. These behaviours often matter more in daily use than a successful demonstration with every system available.
Identify the client's responsibilities for source data, supplier contacts and access. Put realistic dates and owners against those dependencies. A delivery timetable can only be assessed properly when the work expected from the business is visible.
Compare the evidence behind delivery milestones
A milestone should describe an assessable outcome. “Development completed” leaves questions about what has been tested and what the business can review. A milestone tied to specific workflows and acceptance evidence makes progress easier to understand.
Ask how users will see and evaluate the work during development. Regular demonstrations can reveal misunderstandings early, but the review needs representative tasks and decisions. A sequence of attractive screen tours may leave important workflow questions unresolved.
Review the testing responsibilities. Distinguish developer checks, integration testing, user acceptance, performance and other relevant verification. Ask what evidence the supplier will provide and what the client team must contribute before release.
Discuss the effect of a failed acceptance case. Establish how issues are recorded, prioritised, corrected and retested, and how unresolved limitations enter the launch decision. The proposal should give the business a workable way to assess readiness.
Assess what operating the application will require
List the recurring services and costs, including hosting, platform licences, external API use, monitoring and support where relevant. Ask which figures are estimates, what assumptions drive them and what changes as use grows. Compare the same expected workload across proposals.
Clarify who maintains the application and how updates are introduced. The business needs to understand access, deployment, recovery and the process for investigating a fault. A finished build still needs an operating arrangement.
Review the handover materials and access the organisation will receive. Ask about source repositories, configuration records, documentation and the ability of another competent team to support the system. Have the appropriate business owners review the associated commercial terms rather than inferring rights from a technical description.
Ask the supplier to demonstrate a realistic support scenario. If an integration stops receiving enquiries, who notices, who investigates and what information is available? The answer reveals how the proposed service works when it matters.
Resolve questions before scoring the options
Send each supplier a focused clarification list based on gaps in its proposal. Keep the questions specific and share relevant new requirements consistently. Record the answers alongside the original proposal, so the comparison reflects the actual offered arrangement.
Score the options against agreed criteria with short reasons. Consider workflow fit, evidence, uncertainty, delivery capability, operating effort and cost. Avoid a precise-looking score that conceals unanswered questions or weights every criterion equally by accident.
Giraffe Digital's digital strategy service considers the systems supporting business and customer journeys. Comparing software proposals through those journeys helps the organisation make a clearer decision about value, responsibility and demonstrated outcomes.
Frequently asked questions
How should we give suppliers a common problem to respond to?
Describe the work the business needs to improve, the people doing it and the current difficulties. Include examples of important tasks and their outcomes. A proposal for "a customer portal" can hide very different interpretations unless the underlying journeys are clear. Supply relevant constraints such as existing systems, data sources, required roles and operating hours. Distinguish established requirements from ideas that need investigation. This helps suppliers state which parts of their estimate are supported and which rely on assumptions. Understand the problem, users and constraints before committing to a build. Discovery can establish the evidence needed for a reliable commercial implementation scope. Confirm what remains uncertain and how it will be investigated. Our website discovery planning guide provides the related checks.
How should we examine discovery and scope control?
Ask what the supplier needs to learn before building and what the discovery output will be. Useful outputs might include tested workflow assumptions, a data model outline, integration findings and a prioritised release scope. The details should match the uncertainty in your project. Clarify whether discovery changes the implementation estimate and how the business makes the next decision. A staged proposal can be sensible when unknowns are material, provided the outputs and decision points are clear. It should not leave the organisation unable to assess the value of the first stage. Identify the minimum useful release and the capabilities proposed for later. Ask how the initial release will operate with existing systems and manual tasks.
How should we inspect integration and data assumptions?
List every external system the application will use and compare the proposed responsibility for connecting it. Ask whether the supplier has verified access, available interfaces and relevant limits. An integration estimate based on an assumed API can change significantly when the actual system is examined. Check the data migration scope separately from ongoing integration. Moving historic records, preserving relationships and validating the result are different tasks from connecting future events. A proposal that mentions "CRM integration" may cover only one of them. Ask how the application handles an unavailable dependency or an ambiguous response. The business needs a clear account of retries, duplicate prevention and cases requiring investigation. These behaviours often matter more in daily use than a successful demonstration with every system available.
How should we compare the evidence behind delivery milestones?
A milestone should describe an assessable outcome. "Development completed" leaves questions about what has been tested and what the business can review. A milestone tied to specific workflows and acceptance evidence makes progress easier to understand. Ask how users will see and evaluate the work during development. Regular demonstrations can reveal misunderstandings early, but the review needs representative tasks and decisions. A sequence of attractive screen tours may leave important workflow questions unresolved. Review the testing responsibilities. Distinguish developer checks, integration testing, user acceptance, performance and other relevant verification. Ask what evidence the supplier will provide and what the client team must contribute before release. Discuss the effect of a failed acceptance case. Establish how issues are recorded, prioritised, corrected and retested, and how unresolved limitations enter the launch decision.
How should we resolve questions before scoring the options?
Send each supplier a focused clarification list based on gaps in its proposal. Keep the questions specific and share relevant new requirements consistently. Record the answers alongside the original proposal, so the comparison reflects the actual offered arrangement. Score the options against agreed criteria with short reasons. Consider workflow fit, evidence, uncertainty, delivery capability, operating effort and cost. Avoid a precise-looking score that conceals unanswered questions or weights every criterion equally by accident. Giraffe Digital's digital strategy service considers the systems supporting business and customer journeys. Comparing software proposals through those journeys helps the organisation make a clearer decision about value, responsibility and demonstrated outcomes.
