How to Choose a Development Partner Without Being Technical
You cannot assess code you cannot read. You can assess how someone thinks, what they ask before quoting, and what they hand you at the end. Those predict the outcome better anyway.
By NinjaNext TechnologiesPublished 4 min read
Key takeaways
- The questions a supplier asks before quoting tell you more than their portfolio does.
- Agree ownership of code, accounts and data in writing before work starts, not at handover.
- Weekly working software is the only progress report that cannot be faked.
- A partner who disagrees with you early is cheaper than one who agrees with everything.
Hiring someone to build software you cannot evaluate yourself is uncomfortable, and most advice about it is unhelpful: check their portfolio, read reviews, ask for references. All reasonable, all easy to present well, and none of it tells you what it is like when something goes wrong in month three.
Here is what we would actually look at, including the parts that are inconvenient for us to write down.
What they ask before they quote
This is the strongest signal available to a non-technical buyer, and it costs nothing to observe.
A supplier who takes your brief and returns a price has priced their assumption of your product, not your product. A supplier who comes back with questions, especially uncomfortable ones about what happens when things go wrong, has started doing the work. The questions themselves are free consulting: they show you what you had not thought about.
Be suspicious of immediate enthusiasm for everything. Every real brief contains at least one thing that is harder than it looks, and someone who has built this kind of system before will know which one it is. If nobody raises a concern, either they have not read it properly or they are not planning to tell you about problems.
Who owns what, agreed up front
Settle this before work begins, in writing, in plain words. It is the single most common source of trouble we hear about, and it is entirely avoidable.
- Who owns the source code when the project ends, including if it ends badly.
- Whose accounts the hosting, database, domain and app store listings are registered under.
- Who holds the signing keys for mobile apps, which cannot be recovered if lost.
- What happens to all of it if you stop working together next month.
The right answer is that you own everything and the accounts are in your name, with your supplier given access. If a supplier is reluctant, that reluctance is the answer to a question you were going to ask later anyway.
How you will know it is going well
You cannot read the code, so you need a different instrument. The only reliable one is working software, often enough that drift cannot hide.
Ask to see the real thing running every week or two, on a link you can open yourself, not a screen recording and not a slide. A percentage complete is an opinion. A demo is a fact. If weekly feels excessive to a supplier, ask what they would show instead, and listen for whether the answer is about your convenience or theirs.
The failure this catches is the common one: a project that is reported as on track for four months and then needs two more, because nobody was looking at the actual thing. We write about why weekly demos beat status reports in how to scope an MVP.
How they behave when you are wrong
At some point you will ask for something that is a bad idea. Perhaps it costs five times what you expect for marginal gain, perhaps it conflicts with something you asked for last month.
What you want is to be told, with the reasoning, before it is built. What is cheaper for a supplier is to build it, bill it, and build the replacement later. You can test for this during the sales conversation by proposing something slightly unreasonable and seeing whether anyone pushes back. Agreement with everything is not good service; it is a transfer of risk onto you.
What you get at the end
Ask what handover includes, in specifics, before you sign. A good answer covers the code in a repository you own, the accounts in your name, written instructions for running and deploying it, and a willingness to spend an hour with whoever takes it over.
A poor answer is vague, or treats handover as an unusual request. Software that only its author can deploy is not finished, however well it works today.
Does size matter
Large firms offer continuity and process; you may not get their best people and you will pay for the structure. Small teams give you direct access to whoever is building it, which usually means faster decisions, with more exposure if someone leaves. Individual freelancers are often excellent and have no capacity for your emergency if it lands during their holiday.
None of these is correct in general. What matters is matching the shape to the job and being honest about the trade-off you are accepting. For a first product where requirements will change weekly, access and speed usually matter more than process. For a system that must keep running for a decade, continuity does.
If you are evaluating us on these criteria too, that is the point of writing them down. The same questions are worth asking of anyone, and the ones about ownership and handover are worth asking in the first conversation rather than the last.
When you are ready to test a supplier against them, start with your brief and see what questions come back. That first reply tells you most of what you need to know.