How to Choose a Development Partner Without Handing Over Your Product

A disclosure first

I co-founded Webskitters, which builds software for clients, so read this with that in mind. The criteria below are the ones I would want any client to apply to us, and the ones I apply when reviewing other partners for organisations that are not our clients.

Decide what you must own

Before comparing partners, write down what stays with you regardless of who builds. At a minimum: product decisions and priorities, the source code and its repositories, cloud and infrastructure accounts, domain names, data, and the credentials to all of them. These should be in accounts you control from the first day, with the partner given access rather than the other way round.

Just as important is a named person on your side who owns technical decisions. That person does not need to write code, but they need to understand the architecture well enough to ask good questions, or have access to someone who can.

Who owns technology leadership is the structural question behind decisions like these, and Do You Need a CTO Yet? Fractional, Virtual or Full-Time works through the options.

Look for evidence of how they deliver

Portfolios show outcomes chosen by the partner. Ask instead how they work. How do they estimate, and how do they report when an estimate is wrong? How is code reviewed and tested? How often do they release, and how do they roll back? What do they document, and where? Who from their side will actually be on your project, and how stable has that team been on other engagements?

The answers matter less than their specificity. A partner with a real delivery process can describe it concretely and show you examples. Vague answers usually mean the process lives in individuals rather than in the way the company works.

Test the architecture conversation

Ask each shortlisted partner how they would approach your problem at an architectural level: the main components, the technology choices and the trade-offs. You are not looking for the most impressive answer. You are looking for one that starts from your constraints, explains why, and is honest about what it does not yet know.

Be cautious of partners who recommend a full rebuild before understanding what you have, or whose preferred stack happens to match every client’s needs. If you are weighing a rebuild, Modernise or Replace? A Decision Framework for Ageing Platforms sets out the questions to ask first.

Agree the exit before you start

Write down how the relationship ends before it begins: notice periods, handover obligations, documentation standards, knowledge transfer and the state the code must be in. Confirm in the contract that intellectual property transfers to you as work is paid for, and that third-party components and licences are recorded.

A good partner will welcome this. A partner who resists it is telling you how the relationship will feel in two years.

Some leadership teams bring in part-time CTO leadership to put this discipline in place before a full-time appointment makes sense.

Where an independent view helps

If nobody on your side can judge a partner’s proposal or architecture, an independent senior review before you sign is usually worth far more than it costs. That is one of the most common uses of a Virtual CTO: reviewing partners’ proposals, architecture and commercial terms, then staying available as the work starts.

Where the partner or vendor decision is material to an investment or a large contract, technical due diligence goes further, testing the technology, the team and any AI claims against evidence. For AI vendors specifically, see How to Test an AI Vendor’s Claims Before You Sign or Invest.

Read alongside CTO vs CIO vs Chief AI Officer: Who Owns AI? and Most Organisations Are Not Bad at Deciding. They Are Bad at Deciding Early..