Why "how much does software cost" has no single answer
"How much does custom software cost" is the same question as "how much does a building cost." A garden shed and a twelve-story office tower are both "a building," but nothing else about them is comparable: not the materials, not the crew size, not the timeline, not the price.
Software works the same way. A simple landing page with a contact form and a multi-tenant SaaS platform with billing, permissions, and a dozen integrations are both technically "software." But the amount of work behind them is nowhere close, and quoting them as if they belong in the same bucket is how budgets get blown before a single line of code is written.
This is also why a Google search for "software development cost" produces numbers that don't agree with each other. Every published figure is describing a different building. A survey of enterprise projects will report numbers in the hundreds of thousands because it's sampling complex internal systems with dozens of stakeholders. A freelancer marketplace will show numbers in the low thousands because it's sampling small scripts and single-feature tools. Neither number is wrong. Neither is useful without knowing what was actually built.
That's why any answer worth trusting starts with project type, not a single dollar figure. Below are realistic ranges, but the more useful part of this article is what actually pushes a project from the low end to the high end, because that's the part you can control.
Rough cost ranges by project type
These are broad, global-facing ranges in USD. Actual cost varies heavily by region, team seniority, and how the agency structures its rates, so treat this as a starting orientation rather than a quote.
| Project type | Typical range | Timeline |
|---|---|---|
| Simple MVP / prototype | $8,000 - $25,000 | 6-10 weeks |
| Mid-complexity web or mobile app | $25,000 - $80,000 | 3-6 months |
| Complex SaaS platform / multi-integration system | $80,000 - $250,000+ | 6-12+ months |
| Ongoing maintenance / dedicated team | Monthly retainer, varies by scope | Ongoing |
Notice the pattern: it's not really the "type" of app that moves the number, it's the amount of custom logic, the number of integrations, and how many edge cases the system has to handle correctly. Two "mid-complexity apps" can land at opposite ends of that range depending on those factors.
A simple MVP typically covers one core workflow end to end, with basic authentication, one or two screens that matter, and just enough polish to test the idea with real users. It's not meant to handle every scenario, it's meant to answer the question of whether people actually want what you're building.
A mid-complexity app adds real depth: a proper admin panel, a handful of integrations, multiple user types, and enough edge-case handling that it can be used by paying customers rather than early testers. This is where most funded startups and small-to-mid businesses land.
A complex SaaS platform is a different animal entirely. Multi-tenancy, granular permissions, billing logic, analytics, and enough integrations that the system is really a hub connecting several other systems together. These projects also carry ongoing architecture decisions, like how to scale the database or separate services, that smaller projects never have to think about.
Maintenance retainers are their own category because they're not building something new, they're keeping something running: security patches, dependency updates, bug fixes, and small feature requests. Most teams underestimate this line item, which is covered in more detail further down.
What actually drives the price up
- Third-party integrations. Payment gateways, CRMs, ad platforms, accounting software. Each integration means reading unfamiliar documentation, handling that provider's edge cases, and building error handling for when their API is slow or down. A project with five integrations is meaningfully more expensive than one with zero, even if the core screens look identical.
- Real-time features. Live chat, live location tracking, real-time dashboards, or anything that needs data to update instantly across users adds infrastructure complexity that a simple request-response app doesn't need.
- The number of user roles and permission levels. An app with one type of user is simple. An app with admins, managers, staff, and customers, each seeing different data and different actions, multiplies the number of screens and test cases significantly.
- Custom design versus off-the-shelf UI. A polished, fully custom interface designed screen by screen costs more time than assembling a clean interface from proven component libraries. Both can look professional; only one requires a designer building every screen from scratch.
There's a less obvious driver worth naming too: how many platforms the software has to run on. A web-only app is one codebase. Add a native iOS app and a native Android app, and you're often looking at three codebases to build and keep in sync, unless the team uses a cross-platform framework, which comes with its own tradeoffs. Every additional platform is close to its own project bolted onto the first one.
Compliance requirements push cost up too, though they're easy to overlook when scoping a project early. Handling healthcare data, payment card data, or data covered by regulations like GDPR means extra work around encryption, audit logging, and access controls that a typical internal tool never has to think about.
What drives the price down without cutting corners
Cutting cost and cutting quality are not the same thing. Here's what actually brings the number down without producing a worse product.
- A tightly scoped MVP. Building the core workflow first, instead of every feature you can imagine on day one, is the single biggest lever. Most of those "someday" features never end up needed once real users are in the product.
- Reusing proven patterns. Authentication, payments, file uploads, and notifications are solved problems. A team that reuses tested libraries and patterns for these instead of custom-building them from zero saves real time without sacrificing reliability.
- Clear requirements upfront. This is the quiet one. Rework caused by vague specs, features described in one sentence that turn out to need five decisions once development starts, is one of the biggest hidden cost drivers in software projects. A clear written scope prevents most of it.
None of this means building cheaply. It means building deliberately. A tightly scoped MVP that nails one workflow will beat a bloated first version every time, because it ships sooner, costs less to validate, and gives you real usage data to decide what to build next instead of guessing.
The projects that go over budget rarely go over budget because of the code. They go over budget because of decisions that got made too late.
Fixed price vs hourly/dedicated team, briefly
The pricing model, not just the total number, changes who carries the risk when something takes longer than expected. Fixed price shifts that risk toward the agency; hourly or a dedicated team shifts it toward the client in exchange for more flexibility as requirements evolve. Both are legitimate, and the right choice depends on how settled your requirements already are.
It's worth knowing this exists as a separate decision from the total budget, because two quotes with the same number attached can carry very different risk depending on which model they use. This distinction deserves its own deeper treatment, which we'll cover in a separate post on the blog.
How to get an accurate quote
The fastest way to get a wildly inaccurate quote is to describe your idea in one sentence and ask "how much would this cost." The fastest way to get an accurate one is to come prepared.
- A written outline of the core features, not every feature you might eventually want, just what the first version actually needs to do.
- The must-have integrations: payment processor, CRM, specific APIs, anything the app absolutely cannot function without.
- A rough sense of user numbers, since a tool for 50 internal staff and a consumer app aiming for 50,000 users are architected very differently.
Agencies can quote far more accurately against specifics like these than against "build me an app like Uber." Vague requests force the agency to either pad the estimate to cover unknown risk, or lowball it and hope the gaps aren't too painful once the real scope surfaces. Neither outcome serves you well.
It also helps to say upfront what you're not sure about. "We know we need user accounts and a dashboard, but we haven't decided on the reporting features yet" is a useful sentence. It tells the agency exactly where the estimate needs a buffer, instead of forcing them to guess.
If you want to see how that scoping conversation actually works in practice, our services page breaks down how we scope and price a project before any commitment is made. The goal on both sides is the same: a number you can actually plan around, not one that quietly grows once development starts.