How to Evaluate a Software Development Partner

Judge the discovery, not the portfolio

A portfolio tells you a firm has delivered something that looks finished. It tells you nothing about whether it was on time, whether the client would hire them again, or how much of the work was done by the people you would be assigned. Case studies are written by the supplier.

The questions they ask in the first conversation are much harder to fake. A capable firm will want to know about your data before your features, will ask what the system has to connect to, and will ask what happens to the business if it goes down. They will want to speak to the people who do the work, not only to you.

Pay attention to whether they disagree with you. A supplier who accepts every assumption in your brief is either not thinking about it or has decided that agreeing is the faster route to a signature. Both are bad signs, and the second is worse.

Ownership, handover and lock-in

Establish who owns the intellectual property, in writing, before work starts. The default should be that you own the code written for you. Where a supplier uses their own framework or components, that is often reasonable, but the licence terms need to be explicit and they need to survive the end of the relationship.

Ask where the code lives and whether you have access to it today. Source control under your own organisation's account, with the supplier's team added as collaborators, is the arrangement that protects you. Code that lives only in the supplier's environment and arrives as a handover at the end is a risk you are carrying for the whole project.

The question worth asking directly: if we ended this engagement next month, what exactly would we have? The answer should cover source code, documentation, infrastructure access, deployment credentials and any third-party accounts held on your behalf. Hesitation here is informative.

What a good discovery deliverable looks like

A discovery should produce a document you could hand to a different supplier and receive a comparable quote from. That is the clearest test of whether it was real work or an extended sales process.

It should contain a process map of how things work now, a proposed solution architecture, an inventory of every system to be integrated with notes on how, an assessment of the data to be migrated and its condition, a risk list with mitigations, and a delivery plan broken into increments with costs against each.

It should also contain things you did not want to hear: requirements that conflict, assumptions that need checking, and parts of the brief the supplier thinks are a bad idea. A discovery with no uncomfortable findings has not looked hard enough.

Warning signs

Some patterns are reliable indicators that a project will go badly, and they are all visible before you sign.

• A fixed quote arrives without discovery. Either it is padded, or it will be revised, or the scope is defined so narrowly that everything you actually need becomes a variation.
• Data migration is not mentioned. It is one of the largest cost drivers in most projects, and a proposal that is silent on it has not been thought through.
• Every question receives a yes. Capable suppliers have opinions about what you should not build.
• The team you meet is not the team who would do the work, and the proposal does not name who would.
• Testing and user acceptance are not described, or are assumed to be entirely your responsibility without that being stated in the price.
• Support after launch is absent from the proposal. Software that is used generates change, and a plan that ends at go-live is incomplete.
• They have never said no to anything. Suppliers who cannot decline work cannot protect your scope either.

Reading a proposal that avoids trade-offs

Every engineering decision costs something. A proposal describing an approach with only benefits has either omitted the trade-offs or not identified them, and you cannot tell which from the document alone.

Ask what alternatives were considered and why they were rejected. The answer tells you whether the recommendation is a reasoned choice or the technology the firm happens to use for everything. Both can produce good outcomes, but you should know which one you are buying.

Ask what would make this project fail. A supplier with delivery experience will answer quickly and specifically, usually mentioning data quality, availability of your subject-matter experts, or scope expanding mid-build. A supplier who says it will be fine has not thought about it.

Run a paid trial first

The most reliable way to evaluate a supplier is to buy a small piece of work before committing to a large one. A discovery phase, a proof of concept, or a single well-defined deliverable gives you direct evidence of how they communicate, estimate, and respond when something goes wrong.

Pay for it. Free work is sales work, staffed and prioritised accordingly, and it will not tell you what a real engagement feels like.

Watch the process rather than only the output. Did estimates hold? Were problems raised early or disclosed at the deadline? Were questions specific and well-timed? Did the people in the kickoff do the work? Those answers predict the large engagement far better than any reference call, and the cost of finding out is a fraction of the cost of finding out later.