Skip to content

How to choose a development partner without getting burned

Twelve questions that separate a studio that will finish from one that will disappear - and the answers to listen for.

By Mercy Atieno,

A large share of the work we take on is rescue work: a system half-built by someone who stopped answering, or delivered in a state nobody can maintain. In almost every case, the warning signs were visible before the contract was signed.

Ask these before you sign

  1. 1Who owns the code at the end? The only acceptable answer is you, in a repository under your account.
  2. 2Can we see a system you built two years ago that is still running? Anyone can show a launch. Show me something that survived.
  3. 3Who specifically will work on this? Names and roles, not 'our team'.
  4. 4What happens if the person who builds this leaves? Listen for documentation and code review, not reassurance.
  5. 5How do we see progress? Fortnightly demos of working software is the right answer. Percentage-complete reports are not.
  6. 6What is your change request process? A written one that exists before it is needed.
  7. 7What is included after launch, and for how long?
  8. 8Will you talk to a past client without you on the call?
  9. 9What technology will this be built in, and how easy is it to hire for that here?
  10. 10What is not included in this quote?
  11. 11What have you told a client they should not build?
  12. 12What would make you turn this project down?

Warning signs

  • A firm quote before anyone has understood the requirements
  • A price far below every other quote, with no explanation of what is excluded
  • No written contract, or one with no scope definition
  • Reluctance to give you access to the repository during the build
  • A portfolio of designs with no live URLs
  • Vague answers about who owns the intellectual property

Reasonable expectations both ways

Good partnerships need something from you too: a decision-maker who is available, feedback within a few days rather than weeks, and honesty about budget up front. The projects that go badly are rarely purely a vendor failure - they are usually a scope nobody defined and a decision nobody made.

You are not buying code. You are buying the ability to keep changing it after the invoice is paid.

Mercy Atieno

Trenax

Working on something this touches on? We are happy to talk it through, whether or not it turns into a project.

Book a call

Tell us what is not working

Thirty minutes, no deck. You will leave with an honest read on feasibility, a price band and a timeline - whether or not you work with us.

We reply within one business day.

Have a project in mind?

Free 30-minute discovery call.

Book a call