How to choose a development team without being technical
If you're not technical, choosing who builds your product feels like deciding blindfolded: every quote promises the same thing and you can't evaluate the code. But you don't need to know how to code to choose well. You need to look at the right signals, and they are about process, not technology. And if you want a second technical opinion before you sign, that is what a fractional CTO is for.
Seven signs of a good partner
1. They ask before they propose. If the first meeting ends with questions about your business (we always start with "what would success look like for you in this project?"), you're on the right track. If it ends with a standard twenty-page proposal, you already know what everything else will be like.
2. They deliver something that works every few weeks. Deliveries every two weeks, with usable software at the end of each one. It's your only real control tool when you can't code: what you can touch can't be dressed up.
3. The code is yours from day one. Repository in your name, plus your own access, domain and data. If the provider keeps the keys, you don't have a partner: you have a landlord.
4. They document as they build. The acid test: ask what you would receive if tomorrow you wanted to continue with another team. The answer should be immediate and specific.
5. They have an exit plan. A good partner works toward no longer being needed: handover, mentoring and scaling down when you build your own team. Be wary of anyone who sets things up to move in for good.
6. They stand behind what they deliver. A written warranty on what they built. If later bugs are billed separately, the incentives are backwards.
7. They use technology with a talent pool. Mainstream stacks (in our case Azure and the Microsoft ecosystem) mean that tomorrow you'll find professionals to carry on the work. An exotic stack is a dependency dressed up as sophistication.
Four red flags
A fixed price without having understood the scope. Everything is a "yes" and nobody pushes back during the sales process. Nobody mentions QA or testing. And the worst one: you can't talk to the people who will actually build your product, only to a salesperson.
The questions you should ask
What do I get in each delivery? Who owns the repository? What happens if I want to pause? What warranty do you give in writing? How does the handover work if I build my own team? Can I talk to one of your clients? Those six questions take apart any weak proposal, and a good partner is happy to answer them.
If you want to see how we answer them: this is how we approach development, and here you can ask us anything you like. No salesperson in between: you get your answer from the people who build.