How to choose a software house - and what to watch for

When choosing a software house, check three things: responsibility for production, the team that will actually deliver your project, and the terms for handing the system over. Portfolio and technology become useful only when they relate to comparable scale, risk, and product stage.

We write this as a supplier, so you are right to be sceptical. The questions below are phrased so you can ask them of us as well — and so a weak answer is visible.

Three questions that reveal the most

1. What do you maintain in production today, and how do you learn about a failure?

Ask for a concrete answer: monitoring, alerts, ownership, response process, backups, restore tests, and an example of how an incident was handled. Delivery that ends at launch is different from responsibility for a working system.

2. Who specifically will write my code?

Know the people, roles, availability, and seniority involved. Ask whether work is done in-house or subcontracted, who reviews code, who understands the business process, and who takes over if a key person is unavailable. A sales presentation is not the delivery team.

3. What does separation look like?

Clarify repositories, domains, hosting, data, documentation, licences, access, handover period, and the ability to continue with another team. A project should not become a hostage to the supplier merely because basic operating access was never agreed.

Nine additional questions

1. What problem and outcome do you think we are trying to achieve?
2. What assumptions are in the estimate, and what would trigger a re-estimate?
3. Which requirements are in scope and which are explicitly excluded?
4. How will we see working increments and give feedback?
5. How do you test key journeys, permissions, integrations, and failures?
6. How do you handle personal data, access, secrets, and audit trails?
7. What happens when an external API or model changes terms or fails?
8. Which ongoing costs should we expect after launch?
9. What evidence do you have from work comparable to our risk, not merely a visually similar portfolio item?

Seven warning signs

• a fixed price with no stated assumptions or acceptance criteria;
• an estimate before anyone asks about users, data, integrations, or current process;
• a promise that AI will be accurate without an evaluation set and human fallback;
• “we use the latest stack” instead of an explanation of why it fits;
• no named owner for maintenance, incidents, or handover;
• a portfolio with no explanation of the supplier’s actual role;
• pressure to choose immediately rather than time to compare scope and risk.

None of these proves that a supplier is bad in isolation. Together, they suggest the proposal is selling certainty that the project has not earned.

Large or small supplier?

A larger company may offer broader specialist coverage and formal processes; a smaller studio may give direct contact and less overhead. Neither size guarantees quality. Compare continuity, access to decision-makers, relevant expertise, code review, delivery process, and the ability to operate the system after launch.

What not to check

Do not choose on logo count, office photos, technology buzzwords, or the lowest opening number alone. Do not demand a fully detailed specification for free before discovery, either: it can encourage made-up certainty. Compare what each proposal assumes, includes, excludes, and makes measurable.

Frequently asked questions

Is it worth paying for an estimate?

A small, unambiguous scope may be estimated from a focused conversation. Complex work often needs paid discovery because useful scope, architecture, risks, and acceptance criteria require real analysis. The key is that its output should be yours and useful regardless of who builds the system.

How do I compare offers that differ several times in price?

Compare scope, assumptions, data readiness, integrations, testing, deployment, maintenance, handover, and what each supplier excludes. A low price can describe a smaller or riskier project rather than the same project done more efficiently.

What if we already have a supplier and something is not working?

First collect concrete evidence: errors, user journeys, access, logs, repository state, agreements, and the outstanding scope. An independent review can separate a technical defect from an unclear requirement, missing client input, or a process decision that software cannot make.

---

We are happy to answer these questions about our own work. See how applications are built or describe your project.