Choosing who builds your software is a higher-stakes decision than most buyers realise, because you are not really buying a product — you are entering a relationship with the people who will shape a system your business may run on for years. Get it right and you gain a partner; get it wrong and you get a half-finished system, a drained budget, and the unenviable job of hiring someone else to fix it. Here is how to tell the difference before you sign.
Ask how they think, not just what they've built
A portfolio tells you what a company has done; it does not tell you how they will treat your problem. The most revealing early question is not "have you built something like this?" but "how would you approach ours?" A good partner responds by asking you questions — about your business, your users, your constraints — because they know that understanding the problem is most of the work. Be wary of anyone who jumps straight to a solution, a technology, or a quote before they understand what you actually need. Enthusiasm to start building is not the same as understanding what to build.
The questions worth asking
A handful of questions separate a real partner from a body shop. Who will actually do the work? — the people who impress you in the sales meeting are often not the ones who write your code, and you want to meet the team who will. How do you handle change? — requirements always shift, and how a company deals with that reveals whether they are a partner or a meter running. What happens when something breaks? — ask about support, response, and who answers at 2am. How will I see progress? — a good team shows you working software every couple of weeks, not a status report. What do you need from us? — a partner who names the decisions and access they will need from you understands that delivery is a two-sided effort. And who owns the code and the data? — the answer should be, unambiguously, you.
The red flags
Some warning signs are reliable. A quote that is dramatically lower than everyone else's is not a bargain; it is a different, smaller project hiding behind the same words, and the gap will reappear as change requests. A company that agrees to everything without pushing back on anything is telling you they will build what you say rather than what you need. Vague answers about who owns the resulting code, or a reluctance to let you talk to the actual engineers, are structural problems. And a partner who cannot say "no" or "that is a bad idea" to you during sales will not protect you from expensive mistakes during delivery, when it matters most.
Why the cheapest quote rarely wins
The instinct to choose on price is understandable and usually costly. Software is not a commodity where the cheapest identical unit wins; the same brief in the hands of a strong team and a weak one produces wildly different results, and the difference does not show up in the demo — it shows up a year later in reliability, in how easily the software can change, and in whether it becomes an asset or a liability. The real price of software includes everything after launch, and a cheap build with an expensive aftermath is the most common way this decision goes wrong. Judge on value and evidence of delivery, not on the number at the bottom of the page.
Trust the process, and your gut
Finally, pay attention to how it feels to work with them before any money changes hands. The discovery conversation is a preview of the whole relationship: if they listen, ask sharp questions, explain trade-offs honestly, and are willing to disagree with you, that is what delivery will feel like. If it feels like being sold to, that is also a preview. You are choosing people, not just a supplier — and the good ones make the decision easy, because working with them is obviously different from the moment you start talking.