How to choose a software development company

Every development company's website looks competent. The work in the portfolio is finished, photographed well, and shipped — you are never shown the project that ran twice as long as quoted, and neither is anyone else. So the portfolio tells you they can build something. It does not tell you what working with them is like, which is the thing you are actually buying.

The differences show up in questions most companies would rather you did not ask. Here are the ones worth asking, including the ones that lose us work.

Ask what they would talk you out of

A company that has never advised a client to build less, or to buy instead of build, or to fix the process before automating it, is a company that takes whatever is asked for. That sounds accommodating and it is expensive. The most valuable thing a technical partner does early is narrow the problem, and narrowing it usually means a smaller project.

If the answer to "what would you tell us not to build?" is a pause, that is your answer.

Ask who is actually writing the code

Not "do you have senior developers" — everyone says yes. Ask who specifically works on your project, whether they are employed or contracted, and what happens if that person leaves mid-build. Small studios are often better than large ones for this reason, and worse for another: fewer people means less cover. Both are fine. Not knowing which you are getting is not.

Ask what happens when it takes longer

Because it will. Every project meets something nobody anticipated. What matters is what happens then: who absorbs it, how you find out, and whether the conversation happens in week two or week nine.

A company that has never overrun is a company that has not done much, or is not telling you.

Ask about the handover before you start

Who owns the code? The answer must be you, in a repository you can access, from day one — not at the end, not on request.

Who owns the hosting and the domain? Accounts in your name, with your billing. A partner who holds these is a partner you cannot leave, and that is a commercial position, not a technical one.

What does it cost to change something small? Ask for a real example. A new field on a form, a new page. If the answer is a quoted project every time, budget for a site that stops being updated.

The question that reveals most is not about their best work. It is what happens if you want to stop working with them.

What a portfolio does not tell you

It does not tell you whether the client got what they wanted or settled. It does not show the timeline. And it never shows the projects that did not finish — which every company has and none publish.

Ask for a reference from a project that went badly. The answer is more informative than the reference itself: a company that can describe a difficult project honestly, and what they changed afterwards, is telling you something real. One that claims there were none is telling you something too.

Fit matters more than capability

Most competent companies can build most things. The failures are rarely technical — they are mismatches. A studio used to enterprise processes will find a fast-moving small business chaotic, and the small business will find them slow and expensive. Neither is bad at their job.

Ask who their typical client is. If it is not roughly you, be careful even if the work is excellent.

And the unglamorous one

How quickly do they reply now, before you are paying them? That is the fastest they will ever be. If a proposal takes a week when they want the work, form a view about what a support request looks like in month eight.

If you are still working out whether you need custom software at all, that is a different question and worth settling first — the answer is often no, and a partner worth having will say so.