A polished proposal is useful, but it is not evidence that a supplier can understand your system, make sound technical decisions or leave the product in a maintainable state. The selection process should make those things visible before a contract is signed.
This guide explains how to choose a software development company using a six-evidence test. It is designed for a new application, a substantial platform change or a long-running product relationship. For the earlier question of whether custom development is the right route at all, use the build-or-buy software decision framework first.
Start With the Decision You Are Actually Making
“Choose the best software company” is too vague to evaluate. Define the buying decision in operational terms:
- Outcome: What must become possible for users or the organisation?
- Boundary: Which work belongs to the supplier, your team and other vendors?
- Constraint: Which dates, systems, policies or operating conditions cannot be ignored?
- Evidence: What will demonstrate that the outcome works?
- Ownership: Who will run, change and support the system after release?
The GOV.UK Digital, Data and Technology Playbook describes a lifecycle covering preparation, supplier selection, evaluation, award and contract delivery. Private organisations do not have to copy public procurement, but the sequence contains a useful principle: define the need and evaluation method before comparing suppliers.
Turn that definition into one short brief. Give every serious candidate the same version. A supplier can then question the assumptions rather than guessing what the buyer wants to hear.
The Six-Evidence Test
Score each area against material supplied by the candidate. A confident answer without an artefact, example or named responsibility is still only an assertion.
1. Outcome Evidence
Ask the company to restate the problem in its own words and separate the desired outcome from the proposed features.
Useful evidence includes:
- a concise outcome statement;
- the user groups and workflows affected;
- assumptions that require discovery;
- dependencies outside the supplier's control;
- a first definition of acceptance.
Be cautious when the proposal jumps directly to screens, frameworks or a fixed feature list. A supplier may recommend custom software development or a web application, but it should be able to explain why that approach fits the workflow and constraints.
A strong response can also identify when custom development is unnecessary. That is a better signal than enthusiasm for the largest possible scope.
2. Comparable Proof
A portfolio should help you inspect how the company thinks, not just how finished interfaces look.
Ask for one or two relevant examples and request the boundaries around each example:
- What part did the supplier actually deliver?
- Which constraints shaped the work?
- What was inherited rather than created?
- How were technical and product decisions reviewed?
- What was handed over?
Public examples may be limited by confidentiality. That is reasonable. The supplier should still distinguish public evidence, anonymised explanation and claims that require a reference check. Programmers House labels its Work examples as illustrative scenarios; they should not be treated as client outcomes.
Do not award points for an unexplained logo wall, an attractive screenshot or a technology list that is unrelated to your requirement.
3. Delivery Evidence
Request a sample delivery model for the first meaningful slice of work. It should show how decisions move from question to implementation and review.
Look for:
- Discovery: How will uncertain requirements be tested?
- Backlog: Who prioritises work and accepts changes?
- Engineering: Which coding, review and testing practices apply?
- Assurance: How are accessibility, security and operational risks checked?
- Release: Who approves deployment, rollback and production support?
- Communication: Which decisions need written records, and who receives them?
The answer should fit your organisation. A founder-led product team, an internal engineering department and a regulated service will need different review points.
For a substantial browser-based product, compare this evidence with the scope described on the web application development service. The service label matters less than a clear account of responsibilities, dependencies and acceptance.
4. Security and Data Evidence
Security questions should reflect the data, access and operational risk involved. They should not be a generic certification checklist.
The NCSC supply chain security guidance recommends understanding supply-chain risks, establishing control, checking arrangements and improving them over time. Translate that into questions such as:
- Which people and subcontractors need access?
- How will access be approved, limited and removed?
- Where will source code, secrets, backups and production data live?
- How are third-party packages and services assessed and updated?
- How are vulnerabilities, incidents and material changes reported?
- Which security requirements pass to subcontractors?
If the company will process personal data on your behalf, establish the likely controller and processor roles before work begins. The ICO's current contract guidance covers documented instructions, confidentiality, security, subprocessors, rights requests, end-of-contract provisions and audits. Obtain appropriate professional advice for the actual agreement; a development proposal is not a substitute for legal review.
5. Ownership Evidence
Ask what your organisation will own, control and be able to change.
The answer should cover:
- source-code repositories and access;
- cloud and third-party accounts;
- domain, analytics and monitoring ownership;
- data export and retention;
- documentation and decision records;
- licences and reusable components;
- intellectual-property terms;
- change requests and maintenance responsibilities.
Open standards can reduce unnecessary dependence on one supplier. GOV.UK guidance on using open standards links interoperability with compatibility and reduced vendor lock-in. That does not mean every component must be open source. It means formats, interfaces and ownership choices should be deliberate.
A practical test is simple: if the relationship ended next month, could an authorised replacement team understand the system and operate it without negotiating access to its own assets?
6. Exit Evidence
Exit planning belongs in selection, not in the final week of a troubled engagement.
The Sourcing Playbook treats transition, continuity and exit information as matters to plan and maintain. Adapt that principle to the size and risk of your project.
Request an outline covering:
- repository and account transfer;
- current architecture and environment documentation;
- unresolved defects, risks and technical debt;
- data export and deletion;
- knowledge-transfer sessions;
- credentials and access removal;
- support during a defined transition;
- treatment of subcontractors and third-party services.
An exit plan is not a sign of distrust. It makes ownership concrete and reduces ambiguity for both parties.
Request Three Artefacts Before the Final Shortlist
Long proposals can hide differences between suppliers. Three compact artefacts make comparison easier.
A One-Page Delivery Map
Ask each candidate to show the first outcome, major dependencies, named decision owners and review points. The map should expose where your team must contribute.
An Assumption and Risk Log
The supplier should identify what it does not yet know. Include product, data, integration, security, hosting and availability assumptions. Require an owner and a proposed test for each important uncertainty.
A First-30-Days Plan
The plan should not promise a complete product in 30 days. It should show how the team will establish access, validate the problem, confirm architecture constraints, select the first slice and produce reviewable evidence.
These artefacts reveal whether the company can turn uncertainty into controlled decisions.
A Worked Comparison
Consider a hypothetical buyer replacing a spreadsheet-based case workflow.
Supplier A offers the lowest fixed price and a detailed feature list. The proposal does not identify data migration rules, user permissions, integration ownership or post-launch support.
Supplier B proposes a short discovery stage, identifies the migration and access assumptions, maps the first case journey, and explains how the buyer will own repositories and cloud accounts. Its final scope is less certain at quotation stage.
Supplier B has not automatically “won”. The buyer still needs to evaluate cost, capability and commercial fit. But Supplier B has provided stronger evidence about uncertainty and ownership. Supplier A should be given the same opportunity to answer those gaps before a decision.
The useful comparison is not confidence versus caution. It is evidence versus unresolved assumption.
Red Flags That Need a Direct Answer
Pause the process when a candidate:
- guarantees a date or outcome before material dependencies are understood;
- cannot separate its work from subcontracted or third-party work;
- avoids explaining repository, account or data ownership;
- treats security as a final penetration test rather than a delivery responsibility;
- provides no test, acceptance or rollback approach;
- expects production access before responsibilities are agreed;
- refuses a reasonable exit or handover discussion;
- uses client names, metrics or testimonials that cannot be verified.
A red flag is a reason to investigate, not an automatic accusation. Record the question, the response and the evidence used in the final decision.
Build a Decision Record
Use a simple matrix with the six evidence areas. Weight them according to the project rather than using a universal score.
For example, a public marketing site may put more weight on content workflow, accessibility and maintainability. A platform handling sensitive records should give more weight to data roles, access control, incident handling, resilience and audit evidence.
For each score, link to the artefact that supports it. Add unresolved conditions separately. Price can then be compared against a visible scope and risk position rather than treated as a standalone number.
The final record should state:
- the selected supplier and delivery model;
- the evidence that supported the choice;
- risks accepted by the buyer;
- conditions to resolve before work starts;
- responsibilities that belong to the buyer;
- the planned review and exit points.
If you need help turning an existing brief into these evaluation questions, use the project scoping contact route. Bring the outcome, constraints and current system context; a useful first conversation should make the unknowns clearer, not hide them.