How to choose a software development partner (without getting burned)

Most bad software development experiences share a root cause: the person who sold the project isn't the person who builds it. By the time you find out, you've already paid a deposit.

Here's what actually predicts whether a software development partner will deliver what they pitched.

Ask who specifically will write the code — by name, not by role. "A senior engineer" is a job title. "Alex will be your engineer, here's a project they've shipped" is a real answer. If an agency can't name the person before you sign, that's worth noticing, not overlooking.

Ask what happens when the scope needs to change mid-project. Every real project's scope shifts once you see it running. A partner with a clear, pre-agreed process for that ("we'll flag it, quote the delta, you approve before we build it") is more trustworthy than one who promises it won't happen.

Ask to see unfiltered code from a past project, not just a polished case study. A case study shows the outcome. A code sample shows the actual craftsmanship — naming conventions, error handling, whether shortcuts were taken. Most agencies will happily show a demo. Fewer will show real code, and that reluctance tells you something.

Ask what you own when it's done. Full source code access on completion should be the default, written into the agreement — not something you have to negotiate for after the fact.

Notice how they handle "I don't know." A partner who says "we haven't built exactly that before, here's how we'd de-risk it" is more trustworthy than one who claims expertise in everything you mention. Confidence about unknowns is a bigger red flag than an honest gap.

None of this requires technical expertise on your part — it just requires asking specific questions instead of accepting a confident pitch at face value.