Questions to ask before choosing a technical development partner

You are evaluating a working system, not a sales conversation

Choosing a development partner is partly a technical decision, but it is also a decision about judgement, communication and ownership. The team will help turn incomplete business ideas into software decisions. They may need to challenge assumptions, explain trade-offs and maintain a product after the initial excitement has passed.

A polished proposal cannot show all of that. Better evidence comes from the questions a partner asks, the uncertainty they make visible and the way they connect technical choices to users and operations. You do not need to be an engineer to examine those behaviours.

The following questions are designed to start a useful conversation. Strong answers should be specific to your situation. Treat rigid certainty before discovery with caution, particularly when requirements, integrations or inherited systems have not been examined.

1. How will you understand the problem before proposing a build?

Ask what the partner needs to learn about users, current work, intended outcomes, constraints and existing evidence. A credible approach may include stakeholder conversations, workflow mapping, a code or architecture review, product framing and a focused technical investigation. The exact activities should match the uncertainty rather than follow a ceremonial process.

Listen for how they separate the business problem from a requested feature list. A partner should be able to explain what decision discovery will enable and what tangible outputs you will receive. “Discovery” should not be an indefinite period with no shared conclusion.

• Who needs to participate?
• What assumptions will be tested?
• What existing systems or evidence will be reviewed?
• What decisions and artefacts will come out of the work?

2. How do you decide what belongs in the first release?

A useful answer should connect scope to one user outcome, the most important assumptions and the risks that must be handled responsibly. Ask how manual operations, accessibility, permissions, administration and failure states are included. These less visible elements often determine whether a release can be used safely.

Also ask how changes will be assessed once work begins. Some learning is inevitable. The goal is not to pretend scope will never change, but to have a clear way to understand the effect on time, cost and the release outcome before a decision is made.

3. How will technical decisions be made and documented?

Technology should be chosen for product needs, team capability, operational fit and maintainability—not simply because it is fashionable. Ask which decisions are likely to be expensive to reverse, which can remain flexible and how alternatives will be communicated.

You should not need to approve low-level implementation details, but you should be able to understand decisions that affect cost, risk, vendors, data or future ownership. Brief architecture notes, decision records and clear diagrams can preserve the reasoning for the people who maintain the system later.

4. What does quality mean for this product?

“We test our work” is only a starting point. Ask how the partner will address the product's relevant quality risks: core user journeys, security, accessibility, performance, responsive behaviour, data integrity, integrations and deployment safety. A marketing site and a platform handling sensitive records need different depth, but both deserve a deliberate standard.

Ask what will be automated, what requires manual review and what evidence will be shared. Also ask how defects are prioritised and what must be true before a release is considered ready. Quality is easier to manage when acceptance criteria and release checks are established early.

5. How will we see progress and make decisions?

Progress should be visible through working increments, clear written updates and regular decision points. Ask how often you will review the product, who your main contacts are and where scope, risks and open questions will be recorded.

A healthy update does more than list completed tasks. It explains what changed for the product, what was learned, what needs a decision and whether the path to the agreed outcome has moved. Clarify how urgent issues are handled, especially if your team and the partner work across different hours.

6. Who owns the code, accounts and operational access?

Confirm the intended ownership of source code, designs and project artefacts in the agreement. Ask where the code will be hosted, who controls the cloud and vendor accounts, how credentials are managed and which people need access. Avoid arrangements where the business cannot operate or transfer its own product without one supplier's personal account.

Ask how access will be removed when it is no longer needed and how production changes are authorised. These are ordinary operational questions, not signs of distrust. Contractual and legal terms should be reviewed by appropriately qualified advisers for your circumstances.

7. What happens after launch?

Software requires ownership after the first release. Ask what documentation and handover are included, who monitors the system, how incidents are reported and whether maintenance is part of the engagement or a separate arrangement. Clarify how third-party updates, operating costs and security work will be managed.

There is no single correct support model. The important point is that responsibilities and service expectations are explicit. A project can be successful and still become fragile if nobody owns its operation and improvement.

8. What evidence can you share—and what does it actually prove?

Relevant work can demonstrate experience, but look beyond surface similarity. Ask what role the partner performed, which constraints they handled and whether the outcome can be verified. Confidential work may need to be described without a client name; that is different from a vague or inflated claim.

If a team shares internal experiments, confirm that they are labelled as experiments rather than client projects. A thoughtful concept can show craft and technical curiosity, but it does not prove a commercial outcome. Honest boundaries are useful evidence of judgement.

9. How does the commercial model respond to uncertainty?

Ask what is included in the estimate, which assumptions it depends on, how third-party costs are treated and how changes are approved. A fixed scope can be useful when the work is well understood. A staged or iterative model may be more appropriate when the team needs to learn before defining later work.

Be cautious of comparing headline numbers without comparing scope, operating responsibilities and quality expectations. The lowest estimate may omit work you will still need. The highest does not automatically represent the best approach. Look for a model that makes risk and decisions understandable.

Use a small real interaction before a large commitment

Where practical, begin with a bounded activity: a product-shaping workshop, architecture review, technical spike or small delivery phase. Observe whether the team listens, explains decisions, records uncertainty and produces something useful. This is stronger evidence of working fit than a long credentials presentation.

The right partner should help you understand the product and the decisions ahead. Look for clear thinking, proportionate engineering and honesty about what is not yet known. Those qualities matter long after the first proposal is signed.