Contents
Two software proposals can promise the same features while leaving very different work for your organisation. To choose a development company, give each supplier the same representative workflow and compare what its answer establishes, what remains unknown and who would resolve it. The worked example below turns that comparison into a decision about the next commitment. It is a fictional buying exercise, not a customer result or an assessment of any named supplier.
Start with the responsibility you need to buy
Decide whether you need someone to define a product, deliver a known scope, add capacity to your team or take over an existing system. Name the decisions your organisation will retain and those you expect the supplier to own. A team offering implementation capacity is not automatically taking responsibility for discovering the right workflow, coordinating suppliers or operating the application after launch.
Write a short common brief before comparing proposals: the users, the outcome, existing systems, access constraints and the next decision you need to make. Include the inconvenient facts, such as a supplier that cannot yet offer a test environment. These are useful comparison inputs. A long feature list with those uncertainties omitted can make estimates appear comparable when they rest on different assumptions.
Comparison 1: what happens to a normal request?
Supplier A's fictional proposal says the portal includes approvals and an integration. Supplier B describes the request states, identifies where the manager's authority is checked and separates approval from confirmation that the external system received the instruction. B can show a demonstration using a simulated external system, but has not tested the buyer's actual connection.
Record A's answer as a claim awaiting explanation. Record B's answer as a proposed approach with an inspected example, not a verified integration. B has made the boundary easier to discuss; that does not establish compatibility with the real system. Ask both suppliers what access they need, which external behaviour they assume and what result would count as acceptance.
Comparison 2: the external system accepts, then the connection fails
Suppose the external system receives an approved request, but the portal loses the connection before receiving confirmation. Retrying could create a duplicate; doing nothing could leave the request unresolved. Supplier A says failed requests will retry automatically. Supplier B proposes checking the external reference before retrying, while explicitly noting that the external system's lookup and duplicate-handling behaviour is unknown.
Neither answer is enough to approve this dependency for a full build. A has not explained the ambiguous outcome; B has identified information it still needs. The buyer records a follow-up: obtain the external documentation and test access, identify who owns that investigation and agree how an unresolved request will reach an operator. A specific unknown is more useful than a confident promise that hides it.
Comparison 3: a user attempts a decision they cannot make
Supplier A shows an employee screen without an Approve button. Supplier B explains how the application would reject an approval attempt from that employee even if the request were sent without using the screen. B offers an authorised, sanitised example of a permission test from a different system; the buyer has not inspected a test for its own organisation's role model.
A hidden button demonstrates an interface choice, not the complete permission boundary. B's example explains a testing approach, not proof that the buyer's rules are implemented. Write the acceptance question plainly: can an employee approve their own request or read another team's record? Identify who will confirm the roles and who will verify the implemented behaviour before release.
NCSC supplier-assurance guidance supports tailoring evidence requests to the risk and reviewing assurance as circumstances change. It does not make a generic questionnaire or a certificate proof that this workflow is safe. Keep the request proportionate and respect confidentiality; another client's credentials, records and private test results are not appropriate buying evidence.
NCSC: Supplier assurance — having confidence in your suppliers
Comparison 4: a deployment breaks the request journey
Supplier A promises ongoing support. Supplier B names who would monitor the journey, who can restore a previous release and how unresolved requests would be checked after recovery. B's proposal assumes the buyer provides an out-of-hours contact; A has not described a support window. These differences are responsibilities to resolve, not a basis for inventing a reliability score.
Ask both suppliers to describe one failed-release scenario and the recovery evidence they would provide. Clarify the support period, escalation route, account access and any responsibility retained by your team. Compare the included operating work alongside development and launch. A lower proposal may leave your organisation with work it is able to do; the decision should make that transfer explicit.
Comparison 5: another team needs to take over
Supplier A offers a copy of the source code at completion. Supplier B proposes a buyer-controlled repository, documented build and release steps, an account-access inventory and a handover exercise. B excludes transfer of the external supplier's subscription because the buyer must arrange it. That exclusion belongs in the comparison before a contract is agreed.
Source access alone does not show that a successor can operate the application. Ask what a new maintainer would need to build, test, deploy and diagnose a request, and when those materials will be kept current. Clarify control and permitted use of code, accounts and third-party components with the people responsible for the agreement. Do not infer those arrangements from a sales presentation.
GOV.UK's technology guidance encourages adaptable choices and considering existing systems, ownership costs and lock-in. It also encourages testing assumptions about technologies, security and interfaces with prototypes. These are useful questions for this comparison; the government guidance is not a mandatory procurement standard for a private UK business.
GOV.UK Service Manual: Choosing technology — an introduction
Use case studies to ask better follow-up questions
A relevant case study helps you identify what to investigate, but its published scope is not proof of every proposed capability. Veda Software's Powerleague print-portal case study describes venue accounts, central visibility and a supplier ordering flow, alongside workflow mapping, design, build and rollout. A buyer evaluating a portal could ask which responsibilities are comparable and how the proposed approval or integration differs.
The published page does not establish the permission tests, recovery arrangements or contract terms for our fictional service-request portal. Keep those questions open. For any supplier's work, distinguish its actual contribution from a familiar logo or an adjacent project. Where references can be shared with permission, ask about the specific responsibilities and working decisions you need to understand.
Choose the next commitment the evidence can support
In this fictional comparison, B has explained more boundaries, but the real integration remains unresolved for both suppliers. The buyer should not average attractive interface work against that critical unknown. It can ask A to clarify its approach, obtain the missing external information and then decide whether a bounded integration assessment is justified. This example does not select a winner on the buyer's behalf.
For each important question, record the answer, the evidence you inspected, its limits, the unresolved point, an owner and a next decision. Keep claim only, example inspected, proposed approach and verified for this project distinct. Unknown means information is missing; failed means an agreed check was attempted and did not meet its requirement. Neither should silently become a pass.
A discovery phase can be useful when it resolves a consequential uncertainty with defined outputs and an exit decision. It need not be a default extra phase where the scope and dependencies are already understood. Match the commitment to what remains uncertain, compare assumptions and exclusions on the same basis, and carry the agreed responsibilities into delivery reviews and acceptance. Revisit the selection assumptions when the workflow or supplier arrangements change.