It's the first question everyone asks and the one no honest developer can answer in a sentence. "It depends" is true, but it's useless. So here's the useful version: what actually moves the number, what real projects tend to cost, and where the money quietly leaks if you're not paying attention.
Why there's no sticker price
Custom software isn't a product on a shelf; it's a thing built to fit your business, and businesses differ. A booking form and a logistics platform are both "software" the way a shed and an office block are both "buildings." The price follows the scope, and the scope follows what you're actually trying to do.
That said, the cost of any build comes down to four things: how much has to be built, how complex each piece is, how much it has to connect to, and how fast you need it. Push any of those up and the price moves with it.
The four things that drive the cost
1. Scope — how much there is to build
The single biggest lever. A tool that does one job well is a fraction of the cost of a platform with accounts, dashboards, payments, notifications and an admin panel. Most budget overruns aren't bad estimates; they're scope that grew after the estimate.
2. Complexity — how hard each piece is
A form that saves a record is simple. Real-time updates, complex permissions, financial calculations that have to be exactly right, or anything touching compliance — those take more care, more testing, and more time. Two features that look similar on a wireframe can differ tenfold underneath.
3. Integrations — how much it has to talk to
Software rarely lives alone. If it needs to sync with your accounting system, a CRM, a payment gateway or a supplier's API, each connection is its own small project — and the ones without clean APIs are the ones that eat time.
4. Timeline — how fast you need it
Urgency costs money. A comfortable timeline lets a small team work efficiently; a hard deadline means more people in parallel, more coordination, and a premium on top. If the date is flexible, say so — it's the easiest way to keep the price down.
Realistic ranges
With the caveat that your project is your project, here's roughly where things land for a well-built solution — not the cheapest quote you can find, and not enterprise-consultancy rates either:
- A focused tool or MVP — one clear job, limited features: smaller commitment, often the right place to start.
- A multi-feature web or mobile app — accounts, a few workflows, some integrations: the middle of the range, and where most business software sits.
- A complex platform — multiple user types, heavy integrations, real-time data: the top of the range, and usually worth phasing.
If you want a number for your idea rather than a range, our instant estimator asks four questions and emails you a ballpark in about a minute — no call required.
Where money quietly leaks
The quote is only part of the cost. The things that surprise people later:
- Scope creep. "While we're at it, can it also…" is how a fixed budget stops being fixed. Decide what's in and what's a later phase, and hold that line.
- Over-building. Paying to handle a million users when you have a hundred. Build for where you are, with room to grow — not for a scale you're guessing at.
- Skipping the boring parts. Testing, documentation and a plan for maintenance feel skippable until the thing breaks and nobody knows why. They're cheaper to do up front than to retrofit.
- Cheap quotes. The lowest bid often wins the project and loses you the year, because the real cost shows up as rework. Judge on what you get, not just the headline figure.
How to get a smaller, more predictable bill
You have more control over the price than it feels like:
- Start with the core. Launch the one thing that delivers value, then expand once it's earning its keep. Phasing turns one intimidating number into a series of manageable ones.
- Bring a clear problem, not a feature list. "We lose two days a week reconciling orders by hand" tells a good developer far more than a list of screens — and often leads to a simpler, cheaper solution than the one you imagined.
- Be honest about the deadline. If it's flexible, you'll pay less. If it's fixed, say so early so it's priced in rather than discovered halfway.
The right question isn't "what's the cheapest way to build this?" It's "what's the smallest thing that solves the problem, and what will it save or earn once it's running?" Answer that, and the budget answers itself.
The short version
Custom software costs what it costs because it's built for you, not for everyone. Scope, complexity, integrations and timeline set the number; scope creep, over-building and false economies inflate it. Start small, be specific about the problem, and phase the rest. Do that, and you'll spend less and get something that actually works.