The usual way to choose a custom software development company is to brief four of them, collect four proposals, compare day rates and team sizes, look at the portfolios, and pick. It feels rigorous. It is not, because none of those four inputs correlates well with whether you end up with software that works.
Day rates tell you what an hour costs, not how many hours the job takes, and the cheaper rate frequently buys more of them. Team size tells you how many people will be assigned, which on a badly scoped project makes things worse. A portfolio tells you what shipped, not what it took to ship or whether it still runs. And a proposal tells you how good the company is at writing proposals.
Ask what they would refuse to build
The single most useful question in a first meeting is what part of your brief they think is a bad idea. A company that has built enough systems has opinions, and a brief written by a client always contains at least one thing that sounds sensible and will cause pain.
An answer that engages with your actual problem tells you they read it and have judgement. An answer that agrees with everything tells you either they have not thought about it, or they intend to build whatever you specify and charge for the rework when it turns out wrong. The second is a business model. It is just not one that serves you.
Ask to see something that went wrong
Every real project has a moment where an assumption failed: an integration that did not behave as documented, a data migration that surfaced ten years of inconsistency, a performance problem that only appeared under real load.
Ask what happened, who found it, how long it took, and what it cost. You learn two things. Whether they will tell you the truth when it is inconvenient, which is the single most valuable property in a supplier. And whether their process finds problems early, when they are cheap, or late, when they are not.
A company that says nothing has ever gone wrong is telling you they have not built much, or that they are managing your impression rather than your project.
Understand what happens after launch
Custom software is not a purchase, it is a commitment. Dependencies need updating. Operating systems and browsers move. Payment providers change APIs. Integration partners deprecate endpoints. Regulations change, which in this region right now means e-invoicing, data protection and tax rules all moving at once.
So ask what year two looks like. Who fixes a production issue on a Friday evening. What the response commitment is and what it costs. Whether you get the source code, in a repository you control, from day one rather than at the end. Whether the infrastructure is in your cloud account or theirs.
That last one deserves emphasis. If the system runs in your supplier's account, on their credentials, changing supplier becomes a migration rather than a handover, and everyone involved knows it. The cost of leaving is a price you pay every month whether you leave or not.
Judge the discovery, not the estimate
A fixed price for a system nobody has specified is not a commitment, it is a guess with a contract around it. It gets honoured through scope arguments, and those are worse than an honest range.
What you actually want to evaluate is whether the company can turn your vague problem into a specific plan. Pay for a short discovery, deliberately and separately, and treat its output as the real audition. Good discovery produces a written description of your process as it actually runs, a list of the decisions you need to make, an honest account of what is uncertain, and a plan that sequences risk first. Weak discovery produces a feature list and a timeline with no evidence behind it.
Discovery is also cheap relative to being wrong. A few weeks spent getting the specification right routinely saves months, and it is the only stage where changing your mind costs nothing.
The questions that reveal the most
How will you know the project is going badly, and when will I know. What will you need from my team, how often, and what happens if we are slow. Which parts of this have you built before and which are new to you. Who specifically writes the code, and are they employed by you. What does it look like if we stop after phase one.
That last question is the sharpest one. A company confident in its work will describe a coherent phase one you could genuinely stop at. A company whose plan only makes sense if you spend the whole budget will struggle to answer it, and you will have learned something important for the price of asking.
If you are still deciding whether to build at all, custom versus off the shelf is the prior question. If the decision is really about who does the work, in-house team against agency and hiring a team against outsourcing both go deeper. And the questions to ask a web development agency apply here almost unchanged.
