In short
Software cost is driven by scope, the seniority and location of the team, integration and compliance requirements, the quality bar you need, and how much uncertainty remains at the point of estimating. Any figure quoted before those are known is a guess with a currency symbol. This page explains the cost structure so you can interrogate an estimate rather than compare two numbers that were built on different assumptions.
This page does not publish a price list, and the reason is worth stating plainly rather than hiding: a range quoted without knowing your scope, your integrations and your compliance requirements would be a number invented to look helpful. It would also be the number you quote back in a negotiation, so putting a fabricated one here would be worse than useless.
What we can do is explain how the cost is built, because that is what lets you compare quotes that look wildly different for the same brief. For a real figure, describe your scope to us and we will estimate against it. If you want to talk it through, contact us.
Key takeaways
- Two quotes for the same brief usually differ because they assume different scopes, not because one vendor is cheaper.
- The largest single lever is scope, and the cheapest reduction is a feature you agree not to build yet.
- Integration with systems you do not control is the most commonly underestimated line item.
- Compliance and security requirements move cost more than most buyers expect, and cannot be added cheaply later.
- Ask what is excluded, what the assumptions are, and what happens when one proves wrong. The answers tell you whether the estimate is defensible.
Why two quotes for the same brief differ so much
When a brief goes to several vendors, the responses often differ by a multiple. Buyers usually read this as a difference in price. It is almost always a difference in what was assumed.
One vendor scoped a single mobile platform, the other scoped two. One assumed you provide the designs, the other included design. One priced the happy path, the other included the administrative back office nobody mentioned but everybody needs. Until the assumptions are level, the numbers are not comparable, and the cheapest quote is frequently the one that understood the least.
The six things that actually move the number
Cost estimates are mostly a function of these six. Everything else is detail around them.
- Scope. How many capabilities, how deep, and how much of the unglamorous supporting work (admin, permissions, reporting, migration) is included.
- Team shape. Seniority, size, and location. A smaller senior team is often cheaper in total than a larger junior one, because rework is expensive.
- Integrations. Every system you do not control adds discovery, error handling and a dependency on someone else release schedule.
- Compliance and security. Regulated data changes architecture, testing and audit obligations. It cannot be retrofitted cheaply.
- Quality bar. An internal tool for fifty users and a public product for a million have different acceptable failure rates, and the cost follows.
- Remaining uncertainty. The less that is known, the wider any honest estimate must be. Discovery narrows it, which is why discovery pays for itself.
How a defensible estimate is built
A defensible estimate is traceable: you can see which piece of work produced which part of the number. A single figure with no visible structure cannot be interrogated, which is precisely why it is offered.
The sequence is straightforward. Break the scope into pieces small enough to compare against work already done, size each piece as a range rather than a point, add the non-feature work that always exists (environments, CI, release, migration, project management), then state the assumptions and what is excluded. The output is a range with a stated confidence, plus the list of things that would change it.
How to reduce cost without damaging the result
Most cost reduction attempts target the rate, which is the smallest lever available and often self-defeating, because a cheaper team that needs rework costs more. The effective levers are about scope and sequence.
- Cut scope, not quality. Ship fewer capabilities properly. Half-built features cost twice: once to build, once to fix.
- Sequence by risk. Build the riskiest assumption first. Finding out early is the cheapest information available.
- Reuse rather than build. Authentication, payments, notifications and search are usually cheaper bought than built.
- Invest in discovery. A short discovery narrows the estimate and typically removes more scope than it costs.
- Choose the location trade deliberately. An offshore development center lowers hourly cost and reduces overlap hours. That trade suits some products and not others.
Questions to ask about any estimate
Ask these of every quote, including ours. How a vendor responds is informative regardless of the answers.
- What is excluded? The exclusions list tells you more about the number than the inclusions list.
- What assumptions is this built on? An estimate with no stated assumptions has hidden them, not avoided them.
- What is the confidence, and why? A range with a reason is a real estimate. A precise single figure for unspecified work is a sales number.
- What happens when an assumption proves wrong? The answer should be a defined process, not a renegotiation.
- Who exactly is on the team? A blended rate can hide a team far more junior than the one you were shown.
Frequently asked questions
How much does software development cost?
It depends on scope, team seniority and location, integrations, compliance requirements, the quality bar and how much uncertainty remains. We do not publish a rate card, because a figure quoted without knowing those would be invented. Describe your scope and we will estimate against it.
Why are software quotes for the same project so different?
Almost always because the vendors assumed different scopes. One priced one platform and another priced two, or one excluded design, or one omitted the administrative back office. Level the assumptions first, then compare.
What is the biggest driver of software cost?
Scope, meaning how many capabilities, how deep, and how much supporting work such as permissions, reporting and migration is included. It is also the lever you control most directly.
How can I reduce software development cost?
Cut or defer scope rather than quality, build the riskiest part first, buy commodity components instead of building them, invest in a short discovery to narrow the estimate, and choose the team location trade deliberately. Negotiating the hourly rate is the weakest lever and often the most expensive one.
Does AgileTech publish hourly rates?
Not on this page, because a rate quoted without scope is not information you can act on. We give a rate and an estimate against a described scope, with the assumptions and exclusions stated.
