Start with the question you are actually buying an answer to
Before comparing suppliers, be clear about which of three things you need, because they are bought differently. A defined piece of work with a shape you can describe. Capacity, because you know what to build and have too few people. Or a decision, because you are not yet sure what is worth building at all.
A supplier who is good at one is not automatically good at the others. Asking a delivery-focused firm to tell you what to build, or a consultancy to staff a team, produces a bad fit that neither side notices until the invoices start.
What a shortlist should actually test
A portfolio shows what shipped. It does not show what it cost, how long it took, how much of it was rewritten in the first year, or whether the people who built it still work there. So test the things that do predict the outcome.
Directory rankings are worth less than they look. A list of the top software development companies is usually ordered by who paid, reviewed, or submitted a profile — useful for finding candidates, useless for ranking them. Treat it as a source of names and do your own comparison.
- Who specifically will do the work
- Not the company's average experience: the named people on your engagement. Ask what else they are on, and what happens if one of them leaves mid-project. If the answer is vague, you are buying a sales team and being delivered a different one.
- Whether they will tell you no
- Describe something slightly wrong on purpose — a feature that does not fit, a deadline that is not realistic. A supplier who agrees to everything in the sales conversation will agree to everything in delivery too, and that is how scope quietly becomes your problem.
- What happens after launch
- Ask who maintains it, on what terms, and what it costs. A quote that ends at launch is not a quote for working software. Support is either priced now or negotiated later from a weak position.
- Who owns the code
- It should be you, in your own accounts, from the start rather than at the end. If ownership transfers only on final payment, or the supplier keeps parts of it as their framework, you are renting.
Software development pricing models, and what each one hides
Most quotes come in one of three shapes. None is dishonest; each moves risk to a different place, and knowing which is the point.
Before comparing them, be wary of anyone who answers “how much does custom software cost” with a number before asking what it has to do. Custom software development cost is a function of scope, integration and how much is still unknown, and a figure quoted without those is a sales tactic rather than an estimate.
- Fixed price
- You pay an agreed amount for an agreed scope. The supplier carries the risk of it taking longer, and prices that risk into the number. Works when the scope genuinely can be held still. When it cannot, every discovery becomes a change request and the relationship turns adversarial.
- Time and materials
- You pay for the hours worked. You carry the overrun risk, and in exchange you can change direction without renegotiating. Fixed price vs time and materials is really a question about how well you can specify the work, not about which is cheaper.
- A capped or staged budget
- Time and materials with a ceiling, or a series of small fixed pieces. Usually the most honest arrangement for work that is partly unknown, because it keeps both the flexibility and a number you can plan around.
What the software development contract has to say
The contract matters most in the situations nobody expects when signing it. Four clauses do the work.
Ownership of the source code, the documentation and the accounts, stated as transferring during the engagement rather than at the end. Test it by asking for repository access on day one.
What happens when scope changes — who decides, how it is priced, and whether work pauses while that is agreed. This is the clause that decides whether a discovery is a conversation or a dispute.
Exit. How much notice, what gets handed over, and in what state. A supplier confident in their work makes leaving easy, because they do not expect you to want to.
Support after launch: response times, what counts as a defect rather than a change, and what it costs. Agree it before launch, when you still have leverage.
Signals that a supplier will be expensive in ways the quote does not show
A quote far below the others is not a bargain. It usually means a different scope was understood, or that the gap will be recovered through change requests. Ask what they assumed, and compare assumptions rather than totals.
A proposal that arrives immediately, without questions, describes a generic project rather than yours. Good software development proposals are slower because they involve someone actually thinking about your situation.
Being unable to name a project that went badly. Everyone has one. A supplier who cannot describe what went wrong and what they changed has either not been doing it long or is not being straight with you.
Talking only about technology. The stack matters far less than whether they understood the business problem, and a conversation that never leaves the tooling is usually hiding that they did not.
Questions worth asking every supplier
- What would you need from us to make this work?
- Every engagement depends on the client for something — decisions, access, a person who can answer questions. A supplier who says they need nothing has not thought about it, and you will find out which things they needed when they are late.
- What is the first thing you would build?
- The answer shows whether they think in terms of risk or in terms of features. The first thing should usually be the part you are least certain about.
- How will we know it is going badly?
- Ask for the specific signal and when you would see it. “Weekly demos” is an answer. “Good communication” is not.
- What would make you turn this down?
- It tests whether they have a view at all. A supplier with no conditions will take anything, which tells you what their judgement is worth on your project.
When the answer is not to hire a company at all
Sometimes the honest recommendation is an off-the-shelf product with some configuration, and a good supplier will say so. Custom software earns its cost when the process is genuinely yours, when the integration is the point, or when the thing you need does not exist. Not when an existing tool almost fits and nobody has tried it properly.
And if the need is continuous rather than a project, hiring your own engineers is usually cheaper over a few years than any supplier, whatever the day rate comparison says. The reason to use a company is speed, specific expertise, or not wanting to carry the hiring risk — all legitimate, and all worth being explicit about.