How to Choose a Software Development Partner

Choosing a development partner is difficult because the things that determine the outcome are mostly invisible during the sales process. Portfolios show finished work, not how it got there. Quotes show a number, not what happens when the scope moves. Everyone is attentive before the contract is signed.

These are the questions that, in our experience, actually predict how a project will go — asked as a client would ask them, not as an agency would like to answer them.

Ask what they would not build

Describe your project and ask which parts they would cut from a first release, and whether any of it should not be built at all. A partner worth having will have opinions and will tell you when an existing product would serve you better. One that agrees with everything is optimising for signing, and you will meet the disagreement later, during delivery, when it is more expensive.

Ask who will actually do the work

Meet them. It is common for the people in the sales conversation not to be the people who build the thing. That is not automatically a problem, but you should know it in advance, and you should know whether the team changes halfway through.

Ask how they handle a change in scope

Scope will change — that is normal and not a failure. What matters is the mechanism. A good answer describes a specific process: how a change is identified, priced, and decided on, and who signs it off. A vague answer about flexibility means you will be negotiating during delivery, under time pressure.

Ask what happens if you stop

This is the single most revealing question. If you ended the engagement after phase one, what would you have? The answer should be: all the code, in your own repository; all the data; accounts registered in your name; documentation good enough for another developer to continue.

Any hesitation here is disqualifying. Some agencies build dependency deliberately — accounts in their name, undocumented deployment, code that is only deployable by them. You will not notice until you want to leave.

Ask to see something unfinished

A portfolio shows polished end states. Ask instead how you will see progress during the project. Weekly working software you can click through is a very different proposition from a monthly status report, and the difference shows up in how early problems get caught.

Ask about the project that went wrong

Everyone with a real track record has one. What you are listening for is whether they can describe it specifically, what they took responsibility for, and what they changed afterwards. An inability to name a single difficult project means either very little experience or a reluctance to be straight with you.

Warning signs

• A fixed price for a large scope before any discovery work. Either the estimate is padded heavily, or the change requests are the business model.
• No questions about your business. If the conversation is entirely about technology, the software will be built around technology rather than around what you need it to do.
• Certainty on timelines for work nobody has scoped yet.
• Unwillingness to put you in touch with a past client.
• Pressure to decide quickly, or a discount that expires. Serious work does not need urgency manufactured around it.
• Technology chosen before the problem is understood.

What good looks like in practice

A good partnership is quieter than people expect. You know what is being worked on this week. You see it at the end of the week. Problems reach you early, while they are still small. Estimates change and you are told why. Nothing important is decided without you, and nothing trivial requires you.

If you find that, the technology choices matter far less than you would think. If you do not, the best stack in the world will not save the project.