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.

Compare quotes by their assumptions, not their totals

When two quotes for the same brief are far apart, the gap is almost never one team being greedy. They priced different things. One assumed two kinds of user and the other assumed five. One included moving your old data and the other left it out. One counted three weeks of testing and the other counted three days.

Ask each company to list what it assumed, in writing, and lay the lists side by side. The cheapest quote is often the one with the longest list of things it quietly left to you. The ranges and what moves a project between them are worth reading before the quotes arrive, so you know which assumptions to look for.

If a company will not say what its number assumes, treat the number as the first offer in a negotiation, not as a price.

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.

Start with a small piece, and pay for it

Before signing for the whole project, ask whether you can buy a small first piece: a written scope, a clickable prototype, or one working feature. Two to four weeks is enough. It costs more per week than the full project will, and it is the cheapest way to learn how the company behaves when something is unclear.

Watch what happens in that first piece. Do they ask questions that narrow the work, or do they agree to everything? Do they tell you early when something is harder than it looked? Is what they hand over something you could give to another company and keep going?

That last point is the real test. A first piece that is only useful if you stay with the same company is a lock-in with a small price tag. Some companies will not do it, because they want the large contract signed first. That is worth knowing before you sign, not after. It is also the version that costs us a sale when you read the first piece and decide the project is smaller than you thought, or not worth doing. We would rather that than a long build on a brief nobody tested.

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.

Before the first meeting, get a rough range from the cost calculator. Not to negotiate with — to notice when a quote is far outside it, in either direction, and ask why.

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.