← Blog

How to Choose a Technology Partner (and How to Tell Early If It Is Going Wrong)

ControlPoint Advisory · 8/21/2026

How to Choose a Technology Partner (and How to Tell Early If It Is Going Wrong)

Choosing a developer is a bet on judgement, not price. Here is what to look for before signing and the warning signs to watch for in the first month.

Most failed software projects were visibly heading for failure within the first four weeks. The signals were there; nobody knew to read them.

This is a guide to picking a technology partner, and — more usefully — to noticing early when the choice was wrong, while you can still do something about it.

Before you sign

Ask them to disagree with you. Present your plan and see whether they push back. A partner who agrees with everything in the first meeting is either not listening or not experienced. You are buying judgement; if they will not exercise it during the sale, they will not exercise it later.

Ask what they would not build. A good answer exists: "we would not build the reporting module in phase one, because you will not know what you need until the data is real." Anyone who says yes to every scope item is planning to bill you for the discovery you should have done together.

Ask about a project that went badly. Everyone has one. The useful part is the diagnosis. "The client kept changing requirements" is a weak answer — managing change is the job. "We under-scoped the data migration and did not surface it until it was late" is a strong one, because it names their own mistake.

Check the handover story. Who owns the code? Where does it live? If you engaged a different developer next year, what would they receive? If the answer is vague, you are buying a dependency, not a system.

Speak to a reference who is two years in. A client three weeks after launch is happy with everyone. A client two years in knows what the maintenance was like, whether support was answered, and what the true cost turned out to be.

What a good first month looks like

Week one: they ask more than they tell. About your process, your exceptions, who does what, what breaks today. A partner who starts designing screens before understanding your workflow is building a guess.

Week two: you get a written scope you can argue with. Specific enough to disagree with. If you read it and cannot identify anything to correct, it is too vague to hold anyone to.

Week three: something is visible. Not necessarily working — a clickable flow, a prototype, a data model diagram. Something you can react to.

Week four: the first honest bad news. There is always something: a rule that is more complex than assumed, data messier than expected. A partner who has surfaced nothing uncomfortable by week four is either not working or not telling you.

Warning signs in the first month

  • No written scope. Everything by phone and WhatsApp. When there is disagreement later, there is nothing to refer to.
  • All progress is verbal. "It is going well" for three weeks running with nothing to look at.
  • Every question gets a yes. Especially scope questions. Real constraints exist; a partner who never mentions them is deferring the conflict.
  • You cannot see the work in progress. You should have access to a running staging version well before launch, not a big reveal at the end.
  • They will not explain a decision in plain language. Technical choices have business reasons. Someone who cannot explain the reason may not have one.
  • The estimate never changes. As scope grows, an unchanged timeline is not efficiency; it is a number nobody is maintaining.

Fixed price or time and materials?

Both work; both fail in specific ways.

Fixed price transfers risk to the vendor, who prices that risk in. It works when scope is genuinely well defined and you are willing to keep it fixed. It goes wrong when you need to change something — every change becomes a negotiation, and the incentive on the vendor's side is to do the minimum that satisfies the letter of the spec.

Time and materials works when you want flexibility and are prepared to stay involved. It goes wrong when nobody is watching the burn.

A middle path we prefer: fixed price per phase, with each phase small enough to scope honestly — six to eight weeks — and a genuine decision point between phases. You keep the ability to stop.

The clause that matters most

Whatever the contract shape, secure these:

  • The source code and data are yours, in a repository and account you control, from day one — not delivered at the end.
  • You can export all data at any time in a standard format.
  • Nothing critical runs on an account only the vendor can access.

A partner confident in the relationship will agree to all three without discussion. Hesitation here tells you what the relationship is really built on.

If it is going wrong

Do not wait for the deadline. Call a meeting, put the specific concerns in writing, and ask for a revised plan with dates. A good partner will welcome it — they usually know already and have been reluctant to raise it.

If the second plan also slips without explanation, stop. A project killed at month two costs you month one. A project killed at month eight costs you eight months and the credibility you spent internally to fund it.

We work in phases for exactly these reasons. If you want a second opinion on a project already underway, book a consultation.

Found this useful? Share it.