How Do You Choose a Software Development Partner? Check the Work, Not the Pitch

How to choose a software development partner comes down to one rule: judge them on what you can check for yourself, and give the sales pitch little weight. Open their live work. Meet the people who will build yours. Find out who will own the code and the accounts. Then give them one small, real piece of work before a big one. Nearly every guide to this question is written by a company that sells development.

Who writes the advice on choosing a development partner?

Search "how to choose a software development partner" and look at who wrote each result. All nine ordinary results on the first page, read on 16 October 2026, came from companies that sell software or web development, with an AI summary above them.

Most of that advice is sensible: define your goals, look at the portfolio, ask about the process. But a seller tends to write a checklist that its own company passes. So the checks below are ones you can run yourself, without taking anyone's word for it. They work the same whether you run a business that needs software built or an agency that needs a delivery partner behind its own name.

How to choose a software development partner: five checks you can run yourself

Each of these takes an afternoon at most, and none of them needs technical knowledge.

Open their live work, not their screenshots

A portfolio of images proves that someone can design. Ask for links to live sites and apps, open them on your phone, and ask three questions: which parts did you build, which do you still maintain, and for how long? Work that is still running years after launch says more than a launch-day screenshot. Where a partner's best work is under a non-disclosure agreement, a good partner says so plainly and walks you through the approach on a call, without inventing a case study to fill the gap.

Meet the people who will build it

The person on the sales call is often not the person who writes your code. Ask to meet the developer or the lead who will do the work, and have them explain a past project in their own words, without jargon. Then ask what happens if that person leaves halfway through your project. A partner who can name the backup person has thought about it before you asked.

Find out who will own the code, the accounts and the domain

Your hosting, domain, app store accounts and code repository should be in your name from the first day, with the partner invited as a user. If the partner holds them, leaving becomes slow and expensive, even when everyone is friendly. The detail of what to hold and why is in who should own your software accounts.

Read reviews they did not hand you

References that a partner chooses are their happiest clients. Reviews on independent review sites are harder to curate. Read the low scores as well as the high ones, read what the reviewers say went wrong and how it was fixed, and look for reviewers whose business looks like yours.

Notice how they say no

A partner who agrees on the first call to every feature, at the deadline and price you named, is either not listening or planning to argue later. Good partners ask about the business reason behind a feature and point out the part that will cost the most. Then they suggest a smaller first version. After the first calls, ask yourself which partner asked the better questions.

How to choose a software development company when the proposals look the same

Three proposals often list the same technology, similar timelines and prices within a range of each other. Knowing how to choose a software development company from three similar proposals is mostly about reading what each one leaves out. The same checks answer how to choose a web development company for a marketing site or a shop.

How many partners should you talk to?

Talk to three. One gives you nothing to compare, and more than four turns choosing into a second job. Send the same written brief to each, run the five checks on all three, and compare the questions they send back before you compare the prices. The partner whose questions show they understood your business usually understands your project too.

What to compare in the proposals

Put the proposals side by side and compare these rows.

For the questions to ask in the meeting itself, five questions to ask before you hire a dedicated developer covers contract terms and how to read the answers you get.

Should you test a development partner with a small project first?

Yes. Pay for one small piece of real work, because it tells you more than any number of calls.

What makes a good first piece of work?

Pick something that matters but would not hurt the business badly if it went wrong: a landing page, one feature on an existing app, an integration, or a two-week sprint on one item from your list. It should touch your real code or your real systems, so you see how the partner works inside your setup, and it needs a clear finish line that you both agree on in writing. Plan one small change halfway through as well, because how a partner handles change is what you will live with for years.

What should you watch while they build it?

Ask yourself four questions as the work goes on.

1. Did they ask good questions before they started?
2. Did you see progress during the work, or only at the end?
3. How did they handle one change you asked for halfway through?
4. Is the code in your repository, and can another developer read it?

Watch the payment terms as well. We send our invoice only after the client has seen the work, and two of our clients have paid us every month since 2017. A partner who wants a large deposit before you have seen anything is asking you to carry the risk before they have earned your trust.

Fixed price, hourly or a dedicated team: which suits your project?

How you pay shapes how the partner behaves, so choose the model on purpose.

Many partnerships start in one model and move to another. A small first piece to test the partner, then monthly time once trust is earned, is a common path. Whatever the model, read the notice period and any minimum term, and make sure you know how you would leave before you start.

What should an agency check in a white-label development partner?

If you run an agency and the partner will build work your clients see under your name, add four checks to the five above.

• They work under your brand and never contact your client unless you ask them to.
• A mutual non-disclosure agreement and a non-circumvention clause are signed before you share any client details.
• Their working hours overlap yours enough for a daily check-in, and they can join a client call as part of your team when you want them there.
• They can show work built for other agencies, or walk you through it on a call where it is under a non-disclosure agreement.

After that, test the partner the way any business would: with a small first piece, built in your repository and delivered the way your clients expect. For how a partnership like this runs in practice, see the white label development partner page.

What are the warning signs of a bad development partner?

• They say yes to everything on the first call.
• You cannot open any live work, and nobody explains why.
• The senior person from the sales call disappears after you sign.
• Your code, hosting or domain sit in their accounts.
• They want most of the money before you have seen anything.
• There is no written way to request and price a change.
• Nobody can tell you what happens to bugs after launch.

One of these on its own is worth asking about before you decide. Two or three together are usually reason enough to choose another partner.

Pick a partner whose work you have opened and whose builders you have met, then ask yourself whether you could live with their way of working for years. Run the checks above on every name on your shortlist, including ours. If you would rather start with a team that already works this way, the software development partner page explains how a monthly arrangement with Boffin Coders runs, and a short first piece is the place to begin.