The short answer: the agency that should win your project is rarely the one with the flashiest portfolio or the lowest number. It is the one that can explain, in specific terms, how they will decide what to build, who will do the work, and what happens when your assumptions turn out to be wrong. Everything else is presentation.
Buying software is a procurement decision, not a design-award decision. Here is what actually separates one software development agency from another, the pricing models you will be quoted, and the questions that reveal whether a team can really deliver.
What actually differentiates one agency from another
At the pitch stage almost every agency looks identical: a clean website, a row of logos, a confident process diagram. The differences that matter are structural, and usually visible only if you ask directly.
- Who does the work. Some firms sell with senior engineers in the room and staff the build with whoever is free. Ask who is on the team, by name and role, and how much of their week your project gets.
- How they handle discovery. A team that will not spend time understanding your domain before quoting is either selling a repeatable product or guessing.
- What they have built that is genuinely similar. Not “we have worked with healthcare clients” but “we have built multi-tenant scheduling with eligibility checks.”
- Who owns the output. Repository, cloud accounts, domains and design files should be in your name from day one, not transferred on request.
- How they communicate. Working software shown weekly beats status reports. If the only evidence of progress is a slide deck, you are watching reassurance rather than progress.
Agencies rarely fail because they cannot write code. They fail because nobody forced the hard product decisions early, or because the person who sold the project was never on it.
The pricing models you will be quoted
Nearly every proposal arrives in one of three shapes, or a blend of them. The shape tells you where the risk sits and who is carrying it.
Fixed price
One number for a defined scope. Easiest to budget, hardest to get right, because the agency carries the risk of underestimating and prices it into the total. A fixed price is only as good as the scope document behind it: what is in, what is out, how change requests are priced, and what “done” means at each milestone. Of two fixed quotes, the cheaper one usually just contains assumptions you have not seen. It suits work you already understand — a defined integration, a well-specified internal tool, a rebuild of something that exists.
Time and materials
You pay for hours worked, usually at different rates per role. It is the fairest model for genuinely uncertain work: research-heavy products, integrations with systems you do not control, anything where the next slice of scope depends on what the last one taught you. The catch is that control moves to your side. You need a prioritised backlog and the willingness to stop when the spend outruns the value.
Dedicated team
You contract a team — engineers, a designer, sometimes a delivery lead — and direct them yourself. This works when you have internal product leadership and need capacity, or when the work is open-ended by nature. If nobody on your side owns priorities, it is an expensive way to learn that you needed a partner rather than a supplier.
| Model | Makes sense when | Main risk |
|---|---|---|
| Fixed price | Scope is well understood and unlikely to move; you need budget certainty | Change orders; a thin scope document hides the assumptions |
| Time and materials | Discovery is part of the work; requirements will evolve as you learn | Cost drift; needs disciplined prioritisation on your side |
| Dedicated team | You have internal product ownership and need ongoing capacity | You are managing, not buying — and managing is now your job |
Many strong engagements are hybrids: fixed-price discovery, time-and-materials delivery, then a fixed price again once the shapes are known. Ask an agency why they chose a model for you, and listen for whether the answer is about your risk or theirs.
Questions that reveal whether they can do the work
- Who is on our team, by name and role, and can any of them be swapped later?
- What did the last project like ours look like, and what went wrong on it?
- How do you handle a requirement that turns out to be much harder than it looked?
- What do you need from us to keep momentum, and what happens if we are slow to respond?
- Which parts of our system would you build, and which would you buy or integrate?
- What would you tell us not to build?
The last question is the most useful one in the room. A team that argues against scope is thinking about your outcome; a team that says yes to everything is selling hours.
Red flags worth walking away from
- A firm price with no discovery and no real questions about your business.
- No named engineers, or a staffing plan that quietly changes after signature.
- Ownership of code, cloud accounts or domains that transfers “at the end”, or only if you ask.
- Timelines with no time for testing, and milestones with no acceptance criteria.
- “Unlimited revisions” — revision limits exist to force a scope conversation. Remove them and that conversation just happens later, worse.
- Portfolio links that no longer open, or references who never reply.
In-house, freelancers, or an agency
The answer is usually a mix. Keep in-house the part that is your business — the domain logic and product judgement no contractor can hold on your behalf. Freelancers are excellent for a single well-scoped piece, such as a specialist component or a migration, and weaker on breadth: one person cannot credibly cover mobile, backend, data and deployment at once. An agency sells you a system of people — several disciplines, coordination and one contract to hold accountable — which costs more per hour and less per mistake, provided the process is real. Whichever mix you choose, someone has to own the outcome.
Frequently asked questions
Should we choose the cheapest proposal?
Only if the scope documents are genuinely comparable, which they rarely are. The lowest quote usually carries the most unstated assumptions, and those assumptions return as change orders or unfinished features. Compare what is included, and what happens when reality diverges.
What should we have ready before talking to agencies?
A written description of the problem, who will use the result, which systems it must talk to, and the constraint that matters most — budget, deadline or scope. You do not need a full specification. You need to describe the outcome well enough that someone can argue with it.
Next step
If you are already holding proposals, compare the assumptions rather than the totals — our breakdown of what an app actually costs is a reasonable place to check the numbers. If you are earlier than that, we will map what you are building, what it integrates with, and what it will cost to run, then quote it in writing with the assumptions listed. Request a scope and quote, or talk it through first if you are still deciding what to build.