How to Choose a Software Development Company

Choosing badly here is expensive in a specific way: you don’t find out for three months, and by then you’ve paid for most of it. Here’s what we’d look at if we were on your side of the table.

Questions that reveal a lot

"Who exactly will work on this, and what else are they working on?" The people in the pitch are often not the people on the project. Ask for names and availability. A small company that says "these two, at roughly 60% each" is telling you more than a large one that says "our team".

"What would you tell us not to build?" A supplier who wants all of your scope is optimising for revenue. Good ones cut things — and can explain why.

"Show us a project that went wrong." Everyone has one. The answer tells you about their honesty, and about how they behave under pressure. "We’ve never had one" means either inexperience or evasion.

"What happens if we want to leave?" Ask about code ownership, repository access, hosting accounts, documentation and handover. The answer should be immediate and boring. Hesitation is your answer.

"How will we know it’s going badly?" Good suppliers describe a mechanism: a demo cadence, a visible board, weekly written updates. Bad ones describe optimism.

"What do you need from us?" Projects fail from the client side at least as often. A supplier who can’t tell you what they need — decisions, access, content, a named owner — hasn’t thought about it.

What to weigh less than you’d expect

A beautiful portfolio. Design portfolios are the easiest thing to make look good, and they say nothing about whether the project shipped on time or whether the code is maintainable.

Company size. Larger means more capacity, not more attention. Smaller means more attention, and a real question about capacity — which is why the honest version is a small core team with a way to scale delivery when a project needs it.

Technology enthusiasm. A supplier who leads with the stack rather than your problem will build something technically interesting.

The lowest price. Underpriced projects are recovered through change requests, junior staffing, or skipped testing. The recovery is always larger than the discount.

Warning signs

• No discovery phase. Straight from brief to quote.
• An estimate with no assumptions or exclusions.
• Reluctance to put you in contact with a past client.
• Proprietary platforms you can’t take elsewhere.
• Nobody technical in the sales conversation.
• Vague answers about who owns the code.
• Pressure to sign quickly.

Good signs

• They ask about your business before your requirements.
• They push back on something in your brief during the first call.
• They can explain a technical trade-off in language you understand.
• They talk about maintenance before you do.
• They give you a written summary of what they heard.
• They tell you a smaller version would be a better start.

The reference call worth making

Ask a past client three things:

1. What went wrong, and how did they handle it?
2. Did the estimate hold, and if not, how was that conversation?
3. Would you use them again for something bigger?

The third question is the honest one. People are polite about suppliers they wouldn’t rehire.

Team structure matters more than headcount

Ask who makes technical decisions and whether that person will be in your project. In large agencies the answer is frequently "an architect who’ll review it at milestones". That can work, but you should know.

The arrangement we’ve chosen deliberately — a small core team, with trusted specialists brought in when a project needs more capacity — exists because the alternative is either a permanently overloaded small team or an organisation whose overhead you fund on every invoice.

Whichever way you go, the thing to establish is simple: who is responsible for the result, and can you talk to them directly?

If you’re evaluating suppliers right now, we’re happy to be one of them — or just to be a second opinion on someone else’s proposal. Ask us anything.