Software Development Cost: What Actually Drives It

A price tag opened like a cabinet revealing six labeled internal compartments — A number you can interrogate beats a number you can only compare.

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, and collect the bands this site does publish for scoped work, which the cost bands section below does. 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

Two framed drawings of the same house, one a bare outline and one fully detailed, above a single shared blueprint — Until the assumptions are level, the numbers are not comparable.

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.

Where the same brief silently diverges

Assumption	The cheap reading	The expensive reading	How to level it
Platforms	One platform, or a web wrapper	Native iOS and Android plus web	Name the platforms in the brief and ask each vendor to confirm
Design	You supply finished designs	Research, design and iteration included	State who owns design, and whether iteration rounds are in scope
Admin and back office	Not mentioned, not priced	Roles, permissions, reporting, audit	Ask each vendor what the operator of the system will use
Data migration	A clean start, no legacy data	Mapping, cleaning and importing years of records	State what data exists today and whether it must survive
Error and edge handling	The happy path only	Failure states, retries, offline behavior	Ask what happens when the third party API is down
Environments and release	One environment, manual deploys	Staging, CI, automated release, rollback	Ask what the release process is and who builds it

Each row is an assumption a quote makes whether or not it states it. Two quotes that disagree on even one row are pricing different projects.

Leveling quotes before comparing them

Send the identical written briefSame document to every vendor, with platforms, integrations and the operator workflow named explicitly.
Require stated assumptionsAsk each vendor to list what they assumed. A quote that arrives without assumptions has hidden them, not avoided them.
Require an exclusions listWhat is not in the number. This list tells you more than the inclusions list, and its absence tells you the most.
Ask for the same breakdownEffort by area: features, integrations, design, testing, release, management. Totals hide, breakdowns reveal.
Reconcile the outliersWhere one vendor is a multiple of another, find the row that differs. That row is usually a scope misunderstanding, and occasionally a lie.

Do this before reading any total. Comparing unleveled quotes rewards the vendor who understood the least.

The six things that actually move the number

Six wall levers of decreasing size, a figure reaching for the largest one which is red — Scope is the largest lever, and the one you control most directly.

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.

Scope dominates, and it is also the one you control most directly. Rate negotiation is the smallest lever on this list.

How a defensible estimate is built

Five stages of assembling a transparent structure from measured, sorted blocks with visible foundations — You can see which piece of work produced which part of the number.

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.

Each step is visible and checkable. A single unexplained figure cannot be interrogated, which is often the point of offering one.

The bands we actually publish, as of 2026

Three progressively longer bands each with a red marker positioned somewhere along its length — A band is meaningful only when the scope is known. Where you land inside it depends on the drivers.

Everything above explains why we do not print a generic rate card, and that reasoning stands. But this site does publish real figures in the places where scope is known, and collecting them here is more honest than making you hunt for them. As of 2026, our mobile app development services page states the bands we quote by complexity: a basic app with a simple UI and a fixed set of features ranges from $5,000 to $50,000, a medium complexity app with integrations and custom workflows costs approximately $50,000 to $120,000, and a complex app with real-time sync, in-app purchases, advanced security, and third-party integrations can run from $100,000 to $133,000.

Delivered projects give the bands a shape that a range alone cannot. Our published case studies include an online ordering system delivered in 4 months by a team of more than 10 people within a $20K to $100K budget range, and a restaurant POS system delivered in 5 months by a team of more than 8 within the same band. Both were fixed engagements with known scope, which is exactly the condition under which a band becomes meaningful.

Read these numbers the way this page has taught you to read any estimate: they are bands for scoped work, not prices for unscoped ideas. A figure near the bottom of a band assumes a tight scope and few integrations; a figure near the top assumes the opposite. Where your project lands depends on the six drivers above, and the fastest way to find out is to describe your scope and let us estimate against it. If you want the location and engagement-model side of the same question, the onshore, nearshore and offshore comparison works through what the rate figure hides.

Upper bounds of the bands stated on our mobile app services page, in thousands of USD. Where a project lands inside its band depends on the six drivers above.

The build price is not the cost

An iceberg with a small construction site above the waterline and large operational rooms below it — The larger column starts the day the build ends.

Every figure discussed so far is the cost of building the system. The cost of owning it starts the day the build ends and continues for as long as the software earns its keep. Buyers who compare vendors on build price alone routinely choose the option that costs more within the first years of operation, because the cheap build was cheap precisely where the running costs are made: architecture, tests, documentation and the release process.

None of this argues for gold-plating. It argues for asking about the second column before signing for the first, because the second column is larger over the life of any system that succeeds, and it is set, mostly irreversibly, by decisions made during the build.

What owning the system costs after the build

Recurring by nature

Hosting and infrastructure: Cloud compute, storage, bandwidth and the third party services the architecture chose. Scales with usage, shaped forever by the build.
Licenses and subscriptions: Every buy-instead-of-build decision becomes a subscription line. Usually still cheaper than building, but it recurs.
Monitoring and security upkeep: Dependency patching, certificate renewal, vulnerability response. Skipping it does not save the cost, it defers it with interest.

Driven by build quality

Maintenance and defect repair: The direct price of the quality bar chosen during the build. Untested code is not cheaper, it is unbilled.
Change and new features: The cost of the next feature is set by the architecture of the last one. This is where a cheap build gets expensive.
Handover and team changes: Documentation and tests are what make a system survivable when people change. Their absence is a cost that arrives all at once.

No figures here, deliberately: every line depends on your scale and stack. The point is that each line exists, and a build decision sits behind each one.

How to reduce cost without damaging the result

A gardener pruning outer branches from a geometric tree whose healthy core bears red fruit — Ship fewer capabilities properly. Half-built features cost twice.

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.

The levers buyers reach for first (rate negotiation) are the weakest. Scope and sequencing do the real work.

Questions to ask about any estimate

A figure examining a document through a loupe that reveals hidden omitted lines in red — The exclusions list tells you more than the inclusions list.

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.

Reading an estimate: signals of a real number

Do this

A range with stated confidenceWide where uncertainty is real, narrow where the work resembles work already done, and honest about which is which.
Visible structureEffort broken down by area, so you can see which piece of scope produced which part of the number.
Assumptions and exclusions in writingThe vendor states what they assumed and what is not included, unprompted.
Named people, not a blended rateYou know who is on the team and at what seniority, and the price follows from that.

Not this

A precise single figure, instantlyPrecision without discovery is a sales number. The confidence it projects is the product being sold.
A total with no breakdownA number that cannot be interrogated was built not to be. That is a negotiating posture, not an estimate.
Silence about what is excludedThe exclusions exist either way. The only question is whether you learn them before signing or after.
A rate quoted without a teamA blended rate can hide a team far more junior than the one presented in the sales calls.

How the estimate is presented predicts how the engagement will run. These signals are readable before you sign anything.

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 generic rate card, because a figure quoted without knowing those would be invented. For scoped mobile work we publish bands: roughly $5,000 to $50,000 for a basic app, $50,000 to $120,000 for medium complexity, and $100,000 to $133,000 for a complex app with real-time sync and third-party integrations. 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.

What does software cost after it launches?

Ownership costs run for the life of the system: hosting and infrastructure, licenses for the components you bought instead of built, security patching, defect repair, and the cost of every future change. The size of those lines is set during the build, by the architecture, the tests, the documentation and the release process, which is why the cheapest build is frequently the most expensive system.

Is the lowest quote usually the best value?

Rarely. The lowest quote is often the one that assumed the least scope, and sometimes a deliberate bid strategy that recovers margin through change requests once switching vendors is expensive. Level the assumptions across quotes first, require exclusions in writing, and treat a vendor who resists stating assumptions as having answered the question.

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.