What Should a Custom Software Project Actually Cost?

Most people asking this question have already been quoted twice and gotten numbers that differ by an order of magnitude. That is not because someone is lying. It is because "custom software" describes a range about as wide as "vehicle."

Here is how the pricing actually works, and what moves it.

What does custom software actually cost?

For a small or mid-sized service business, real projects generally land between $1,500 and $25,000. A tightly scoped audit or single-purpose tool can start around $300. A full multi-user application with roles, reporting, and integrations sits at the upper end.

If you are being quoted six figures for an internal tool that three people will use, something is wrong with the scope, not with your budget.

Why do two quotes for the same description differ so much?

Because the description is doing a lot of unspoken work.

"An inventory system" can mean a spreadsheet replacement that one person updates, or a multi-location system with barcode scanning, reservation conflicts, damage tracking, and a customer-facing availability calendar. Those are not the same project. They are not even the same category of project.

A quote is only meaningful once the scope is written down. If a vendor gives you a number before asking what happens when two customers reserve the same item on the same weekend, that number is a guess.

What actually drives the price up?

In rough order of impact:

Number of distinct user roles. One role is a tool. Three roles is a system. Each role adds its own screens, permissions, and edge cases, and the testing surface multiplies rather than adds.

Integrations with systems you do not control. Talking to your accounting software, a payment processor, or a supplier's API means handling their downtime, their rate limits, and their breaking changes. Every integration is a small ongoing liability, not a one-time build.

Data migration. Moving ten years of messy spreadsheet history into a structured database is frequently the single most expensive part of a project, and it is the part most often left out of quotes. Real data is inconsistent in ways nobody remembers until it fails to import.

Real-time requirements. "Both people should see the change immediately" is a different architecture than "the page updates when you refresh." Ask whether you actually need it.

Compliance. Healthcare, education, and financial data carry requirements that shape the whole build. These are not features to add later.

What drives it down?

Starting from something that already exists. A build that begins from a proven template rather than an empty folder skips the work of re-solving authentication, permissions, and admin scaffolding. That is often the difference between a four-figure and a five-figure project.

Narrowing to one workflow. The most expensive projects are the ones that try to replace everything at once. Pick the single process that hurts most, replace that, and let the rest wait until you have seen the first piece working.

Deferring the admin panel. Early on, a developer editing the database directly is cheaper than a polished management interface nobody has designed yet. Build it once you know what you actually need to manage.

Being decisive. Scope changes mid-build are the most expensive kind of change. Slow decisions cost real money.

What should you expect at each budget?

A few hundred dollars buys a scoped audit: someone looking at how you actually work and telling you what is worth building, what to buy off the shelf, and what to leave alone. If you are not sure what you need, start here rather than guessing at a build.

One to three thousand buys a focused tool that does one job well. A quote form that produces real estimates. A workflow automation that removes a recurring manual step. A small dashboard for one team.

Five to fifteen thousand buys a genuine application: multiple roles, real data relationships, reporting, and an admin interface. This is where most operational software lands.

Fifteen to twenty-five thousand and up buys multi-tenant platforms, heavy integration work, or products you intend to sell to your own customers.

How do you avoid paying for the wrong thing?

Ask three questions before signing anything.

"What happens if we do nothing?" If the honest answer is "not much," you have found a nice-to-have. Build the thing where the answer is expensive.

"What is the smallest version that would still be useful?" A good partner will happily describe a smaller build than the one they quoted. Someone who cannot is selling scope.

"Who owns the code and the data?" If the answer is anything other than "you do," walk. You should be able to take the repository and the database and hire someone else tomorrow.

The part nobody quotes

Software has a running cost after launch: hosting, monitoring, dependency updates, and the small changes that surface once real people use it. Budget roughly ten to twenty percent of the build cost annually. A quote that ignores this is not cheaper, it is just incomplete.

If you want a concrete number for your situation rather than a range, the smart quote walks through the questions that actually move the estimate and returns a package and a starting price before you talk to anyone.