How to choose a software development partner

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.

What questions should you ask before signing?

Take this list into every call:

1. Who will write the code, by name, and can I speak to them before we sign?
2. Which past project is closest to mine, and can I see it running?
3. What happens in discovery, and what do I get at the end of it?
4. How do you handle changes to scope once the build has started?
5. How often will I see working software, not just status updates?
6. Who owns the code, the hosting accounts and the domain?
7. What does support cost after launch, and what is the response time?
8. What would make you turn this project down?

The last question is revealing. A partner who can name what they would not take on is one who knows their strengths.

What red flags should you watch for?

• A firm fixed price before anyone has asked about your users, data or integrations.
• No named people, only "our team".
• Case studies with no live link, no client type and no detail of what was built.
• Pressure to sign quickly, such as discounts that expire this week.
• Hosting or code held in the agency's accounts, with access "on request".
• No written process for handling changes.

Freelancer, agency or in-house team?

A freelancer suits small, well-defined jobs and tight budgets. The risk is continuity if they become unavailable.

An agency or studio suits projects that need several skills, such as design, engineering and SEO, and someone accountable over time.

An in-house team suits products that are central to the business and will be developed continuously for years. It is the most expensive to start and the slowest to hire.

Many businesses start with a studio, then hire in-house once the product is proven, which is why owning clean, well-documented code from the start matters.

How should a good engagement start?

With discovery: a short, focused phase that maps the problem, the users, the data and the integrations, and ends with a written scope and a fixed price. We explain why in why a fixed quote before discovery is a red flag and why we scope outcomes, not features.

You can see how we work, and who you would be working with, on the company page, and real projects running live on our work.