Shortlisting software development companies is mostly an exercise in discarding. Every firm's website says it builds scalable, secure, user centred software, and none of that is checkable. What is checkable is narrower and more useful: what the firm has built in your sector, who would still be working on your project in a year, how it handles work it has already shipped, and what it will put in writing. This page sets out the evidence worth asking for and the answers that should end a conversation early.
Start from work, not from lists
Directory rankings and awards are bought, earned and gamed in unknown proportions, and the order tells you more about the directory's business model than about the firms. A better starting point is software you can see working in your own sector, traced back to whoever built it. Two firms found that way are worth more than ten from a ranking nobody can audit. Where you do use a directory, read its own explanation of how it ranks, and check whether the order changes when you are logged out.
Ask for a reference whose project has finished
Every firm can produce a happy current client, because the invoice is still being paid and the relationship is still being managed. A far more informative request is a reference whose project ended. That conversation covers handover, the final invoice, and what happened when something broke after the team moved on, which are the three moments where the difference between firms actually shows. A firm that cannot produce one in a market it claims years of experience in has told you something.
Meet the technical lead, not the partner
The person who wins the work is frequently not the person who does it. Ask to meet the technical lead who would run your project and ask them to describe the last project they ran: what went wrong, what they changed, what they would do differently. The specificity of that answer is the most reliable single signal available to a buyer with no engineering background, and it cannot be prepared in the way a capability deck can.
The claims that should end a conversation
A guaranteed delivery date given before any discovery, a refusal to name the team, a proposal with no assumptions listed, and an unwillingness to let you own the repository are each, on their own, reason to stop. So is a quote that arrives without questions, because a firm that needed to ask nothing has priced something generic. None of these are technical judgements. They are all things a non technical buyer can notice in the first two meetings, which is where most of the avoidable mistakes in this market get made.
Questions people ask about software development companies
How many firms should I take to proposal?
Three is usually right. Below that you have no comparison; above it the evaluation cost outweighs the benefit and the proposals blur together. Spend the effort you save on deeper due diligence into the three.
Is a larger firm safer?
Size buys continuity and process and costs money and attention. A small firm where the founder writes code can be the better choice for work that needs judgement rather than scale. The risk to manage in a small firm is key person dependency; in a large one it is being staffed with whoever is available.
Should I ask to see code?
Ask for a walkthrough of a real codebase they have permission to show, narrated by the technical lead. You are not auditing the code. You are watching whether they can explain their own decisions clearly, which is the skill you will rely on every week of the project.