Skip to content
Brain Matrix

Technology Strategy

How to choose a software development partner

Portfolios and day rates tell you almost nothing. Six questions that reveal how a partner actually works, the answers worth trusting, and the four engagement shapes with their honest failure modes.

Written by

Nadeem Sheikh

Software Architect & AI Automation Engineer

Published
Reading time
4 minutes
Written for
how to choose a software development partner — a founder or executive comparing options, often after a bad experience

Most selection processes compare the wrong things: portfolio, day rate, team size, and a list of technologies. All four are easy to present well and weakly correlated with how an engagement goes.

What actually predicts the outcome is how a partner behaves when something is unclear, inconvenient or going wrong. You cannot see that in a deck, but you can surface a surprising amount of it in one conversation.

The four shapes, and how each fails

Before comparing suppliers, it helps to know which category you are choosing.

ShapeBest forHow it typically fails
In-house hireLong-horizon ownership of a core systemSlow to start; a single hire is a single point of failure; hard to get senior architecture from one person
Individual freelancerWell-defined, contained workCapacity and continuity; excellent while it works, difficult when it stops
Large offshore teamVolume delivery against a clear specificationSpecification quality becomes everything; the gap between what you asked for and what you meant is expensive
Small senior partnerAmbiguous problems needing architecture and judgementLimited capacity; wrong choice for straightforward volume work, where you would be overpaying for judgement you do not need

None is better. They fail differently, and the honest question is which failure mode you can most afford.

Six questions worth asking

1. "Tell me about a project that went badly and what you did."

The single most informative question, because it is difficult to answer well without a real one.

Weak answers blame the client, describe a scope disagreement as though it were an act of nature, or produce a failure that is secretly a strength ("we cared too much about quality"). Strong answers name a specific decision, explain why it was made, and say what changed afterwards.

2. "When did you last tell a client not to build something?"

If a firm has never talked a client out of a project, one of two things is true: they have not been asked to build anything unnecessary, which is implausible, or they take work they should decline.

Listen for whether they can describe the reasoning. "We told them their process was about to change and to wait six months" is a real answer.

3. "Who will actually be doing the work, and will they be on this call?"

The oldest problem in this industry: senior people sell, junior people deliver. It is not automatically wrong — plenty of work suits mixed teams — but you should know before signing rather than in week three.

Ask directly what proportion of the work the person in front of you will do.

4. "What happens after launch?"

A partner who has thought about this will talk about documentation, runbooks, handover, and the cost of ownership without being prompted. One who has not will talk about launch as an ending.

A useful follow-up: "if we wanted to bring this in-house in a year, how hard would you make that?" The answer tells you whether they build dependencies deliberately.

5. "What would you need to see before giving us a number?"

Anyone who can price a substantial project from a two-page brief is doing one of two things: padding heavily, or planning to renegotiate later via change requests.

A good answer describes a short, paid, scoped diagnostic that produces something you own and can take elsewhere — including to a competitor.

6. "What do you think is wrong with what we have described?"

Asked at the end of a first conversation, this separates people quickly. A partner who has been listening will have a specific reservation. A partner who has been selling will say it sounds great.

You are not looking for agreement. You are looking for evidence they were thinking rather than waiting to talk.

Signals in the commercial structure

A small first commitment. A partner confident in their work will offer a way to try them that does not require betting the project. Fixed-price diagnostics and short first phases are good signs.

Phases you can stop at. If every phase ends with something usable, continuing is a choice. If value only arrives at the end, you are locked in from the start regardless of what the contract says.

Clear ownership of code and infrastructure. You should own the code, the accounts, the domains and the documentation. Any hesitation here is worth pursuing to the end.

No hourly-rate-only pricing on ambiguous work. Hourly billing on an unclear scope puts your interests and theirs in opposition on every decision. It is fine for well-defined augmentation, and poor for anything requiring judgement about what to build.

What we would say about ourselves

For symmetry, the honest version: we are a small senior partner. That makes us a good fit for ambiguous problems where architecture and judgement matter, and a poor fit for high-volume delivery against a fixed specification, where a larger team would serve you better and cost less.

We would rather say that at the start than discover it together in month two.


If you want to work through whether there is a project here at all, book a strategy call. Forty-five minutes, a senior engineer, and a straight answer — including "this is not a software problem" when that is what we think.

Written by

Nadeem Sheikh

Software Architect & AI Automation Engineer

Brain Matrix Solutions is deliberately small so that the person on your first call is the person doing the architecture and the person handing it over. There is no sales layer between us, and nothing gets passed to someone junior after you sign.

Next step

Let's talk about what's holding your business back.

A 45-minute conversation with a senior engineer. We will look at your situation, say what we would do, and tell you if the answer is not software. No pitch deck, no pressure.