Development
How to choose a product development partner: 12 questions before signing
A practical pre-contract review of a development team: delivery, staffing, estimates, QA, security, data, code ownership, launch, and support.
The short answer: compare evidence, not confidence in a sales call
A strong partner does not need to accept every initial idea, promise an exact date before discovery, or present the longest technology list. They should explain how the problem will be tested, who makes decisions, what you will inspect during delivery, how readiness is proven, and what your company retains when the engagement ends.
Ask every candidate the same 12 questions and request a short written answer with a sample artefact: a discovery plan, acceptance criteria, delivery report, release process, or access-handover list. This compares actual boundaries of responsibility rather than the polish of different sales decks.
1. How will you verify that we are solving the right problem?
A useful answer begins with users, the current workflow, constraints, and a measurable change—not a preferred framework. Ask which discovery questions the team will use, whose perspective it needs, which real cases it will examine, and what evidence supports a go/no-go decision.
The evidence is a concise discovery plan and an example of how findings can change the product boundary. If every problem immediately becomes the solution already proposed, the supplier is selling production before validating value.
2. Who will actually do the work, and who owns each decision?
Look beyond the titles in the pitch deck. Ask who covers product decisions, research, design, architecture, engineering, QA, release, and operations at each phase. GOV.UK recommends multidisciplinary teams because digital-service decisions require different skills throughout the lifecycle.
Evidence means the roles or names of the people doing the work, access to an accountable lead, and a clear decision map. Record who can approve scope, accept a journey, stop a release, and replace a team member without losing project context.
3. What will we see before production development begins?
Ask the supplier to separate discovery, prototyping, and production code. Before a major commitment, you should see a problem map, critical user journey, risky assumptions, a prototype, and an explainable boundary for the first release. It need not be a large document, but it must support a real decision.
Evidence is a sample prototype and the questions it was designed to test. Listen for a willingness to discard an idea that does not work; a prototype that can only be approved does not reduce risk.
4. What is included in the estimate, and how is change controlled?
Check whether proposals include the same responsibilities: research, state design, backend work, integrations, migration, content, analytics, accessibility, security, testing, release, infrastructure, documentation, and support. A total price without a responsibility boundary says little about whether two proposals are comparable.
Evidence is an estimate with assumptions, an in/out list, acceptance criteria, and a change-request process. GOV.UK describes agile planning as visible and refined as the team learns; this does not mean an uncontrolled budget when the impact of each change is shown before work begins.
5. How will I see progress and make decisions?
Ask about the cadence of working demonstrations, the shared decision record, access to delivery work, and how risks are raised. Progress should be visible through a working journey and satisfied criteria, not only hours, percentages, or a list of completed technical tasks.
Evidence is a concise status report showing the outcome, decisions, blockers, changes, and the next verifiable result. On your side, appoint a product owner who can respond in time; transparency cannot help when decisions wait weeks for the client.
6. How will you prove quality before release?
Ask which layers of verification fit your risk: code review, automated and manual checks, critical journeys, errors and empty states, permissions, devices, slow networks, integrations, migration, and recovery. Not every product needs the same test suite, but the choice should follow the consequences of failure.
Evidence is a definition of done, a sample test case, and a defect-management rule. Ask who can stop a release, which limitations may be accepted, and how a fix is verified rather than merely marked complete.
7. How is security built into delivery?
'We write secure code' is too broad to evaluate. Ask how the team manages dependencies and secrets, reviews changes, limits access, models threats, handles vulnerabilities, and prepares for incidents. NIST SSDF and OWASP SAMM treat security as practices spanning governance, design, implementation, verification, and operations.
Evidence is a risk-appropriate security checklist, an access model, and an incident-notification process. A certification may be useful, but it does not replace an explanation of the measures that will apply to your product.
8. What happens to our data and third-party services?
Ask which personal and commercial data the team receives, where production, backup, and development copies are located, who has access, how long data is retained, whether subcontractors or external AI tools are used, and what is deleted when the contract ends. The answer depends on jurisdiction and needs legal review by the client.
Evidence is a record of data flows, processors and subprocessors, technical and organisational measures, and contractual return or deletion terms. ICO guidance connects processor selection with sufficient guarantees, a written contract, security, auditability, and end-of-contract provisions.
9. Which non-functional requirements are part of acceptance?
A product can complete its primary journey and still fail because it is slow, inaccessible, unobservable, difficult to index, or unreliable. Ask how the team defines performance, accessibility, compatibility, observability, SEO, and recovery requirements.
Evidence is a measurable criterion and a method for testing it in an appropriate environment. Use relevant WCAG criteria for accessibility and an agreed performance budget tied to critical journeys. Avoid universal numbers that are disconnected from users and consequences.
10. What exactly will our company own and control?
Before signing, list source code, design files, documentation, tests, data, domains, repositories, cloud accounts, store accounts, analytics, keys, licences, and third-party components. For every item, establish who controls it during delivery and after payment, and which restrictions remain.
Evidence is a contract schedule and a handover checklist. Client-controlled infrastructure with least-privilege access for the partner is usually easier to transfer. If the supplier uses a proprietary framework, record its licence, update availability, and whether another team can continue the product.
11. How will launch, migration, and rollback work?
Ask who prepares production, migrates data, verifies completeness, controls domains or stores, observes initial traffic, and decides whether to roll back. Release is a managed operation of its own, not simply the last development task.
Evidence is a release checklist with owners, a backup, go/no-go criteria, rollback, and post-release verification. For external platforms, a credible partner separates its own readiness from store review, DNS propagation, or another independent service.
12. How do support, handover, and exit work?
Clarify warranty obligations, support hours and channels, severity levels, response targets, infrastructure and dependency maintenance, the boundary between a defect and a new feature, and the process for transferring to another team. Undefined support creates conflicting expectations immediately after launch.
Evidence is a support policy, operational runbook, documentation package, and exit plan. A sound handover lets the client keep the product operational if the partner changes; this is not opposition to a long-term relationship but evidence that the relationship is mature.
How to compare answers without false precision
Use one comparison table: question, written answer, evidence shown, exceptions, decision owner, and action required before signing. Do not compress everything into one artificial score. Mark deal-breakers separately, such as no ownership of code, unknown subprocessors, or an inability to access production.
Then run a small paid first stage with a real outcome: discovery, a risk prototype, or a technical audit. It cannot guarantee future success, but it provides stronger evidence of working compatibility, judgement, and transparency than another sales meeting.