How to choose a software house without wasting your money

You're about to sign a contract worth tens of thousands of euros for software that's supposed to run your business — and the uncomfortable truth is that you don't have the tools to tell whether the people in front of you are good, or just good at selling. That's not your fault: you're not technical. But the decision is still yours to make. This is the guide I wish someone had given you before you signed.

Choosing badly doesn't cost you the project: it costs double

When a software house delivers badly, you don't just lose the money you spent. You lose the months spent waiting, you lose the market window that product was for, and in the end you pay twice: someone has to understand somebody else's code, decide what to keep and what to throw away, and rebuild it. The true bill of a wrong choice is almost always higher than the quote that convinced you.

The criteria you normally use don't predict the outcome

Almost everyone picks a software house on the same three signals. The problem is that none of the three says much about how your project will end.

• The beautiful portfolio.A site with polished case studies proves they know how to present themselves, not that they write maintainable code. Screenshots are made by the design team; technical debt doesn't show up in a slide.
• The likeable salesperson.The person who wins you over in the meeting is almost never the person who will write your software. They're paid to get you to sign, not to build.
• The price.Neither the cheapest nor the most expensive protects you. The low quote usually cuts the invisible things that keep software alive over time; the high one guarantees nothing if you don't know what you're paying for.

The signals that actually matter

The ones that predict a good outcome are less flashy, and you can catch them without being technical — because they're about behaviour, not code.

• They ask you uncomfortable questions. A serious software house, before giving you a number, wants to understand the problem: who will use the software, what happens if a certain thing breaks, what you can cut. Whoever quotes you without questioning you is giving you a random number.
• They tell you no.Whoever agrees with everything is selling to you, not advising you. A supplier who explains why an idea is too expensive or too risky is worth more than one who always says "sure, we can do that".
• They're clear about who writes the code.You need to know who, concretely, will touch your project — and what happens if that person leaves. "We have a team" is not an answer.
• They estimate out loud.The good ones explain how they arrived at a number and a timeline, and where the risks are. Whoever estimates with absolute confidence either hasn't understood the problem, or is hiding it from you.

The questions to ask before signing

Bring these to the first meeting. You don't need to understand the technical answers in detail: you need to watch howthey answer — whether they're direct or vague, whether they explain or confuse.

• Do the code, the repository with its history and the infrastructure access stay mine? (The right answer is yes, in writing.)
• Who concretely writes the code, and with what experience? What happens if that person is gone?
• How do you handle testing, and what happens when something breaks in production?
• What is NOT included in the quote? (Surprises live here.)
• If in six months I want to change supplier, what do I take with me, and in what state?

If they get evasive in front of these questions, you already have the information you were looking for. Many of the situations I describe in software agency not delivering start precisely with questions that were never asked at the beginning.

The red flags

• Fixed price on a vague scope.A precise number on a project described in two lines means someone will pay the difference — and it won't be them.
• "We'll handle everything, don't worry about anything." Sounds reassuring; it usually means zero transparency and total dependence on them.
• Ambiguous code ownership. If it takes a discussion to establish that your software is yours, you already know the answer.
• No senior on the project.If the delicate parts are written by someone who's still learning, you pay for them twice: once in bugs, once in rewrites.

How to protect yourself before signing

You don't have to become technical to make a technical choice: you have to put someone technical on your side. An independent second opinion — a technical audit before signing, or in the first weeks of work — costs a fraction of the project and tells you whether the promises hold up: whether the quote is realistic, whether the approach makes sense, whether there are hidden risks.

It's the same principle as a survey before buying a house. If you're building from scratch, it's worth starting with the right structure — I cover it in building a software product. If a project has already gone wrong, it doesn't always have to be thrown away: often it can be recovered. And if you want to train your eye in the meantime, here's how to tell whether your developer is doing a good job.