How Much Does Custom Software Cost for a Small Business?

Search this and you'll get ranges from $15,000 to over $150,000, which is true and nearly useless. The spread isn't vagueness — it's that "custom software" covers a one-screen internal tool and a product with paying subscribers, and those are not the same purchase.

Here's what actually drives the number, so you can estimate your own before anyone quotes you.

Three different things get called custom software

Notice what the middle row assumes: one workflow. The most reliable way to turn a $40,000 project into a $12,000 one isn't finding a cheaper developer — it's wanting less at the start.

What each thing adds

Roughly in order of how much they cost, and each one is a decision you can defer.

Cheap, or nearly free

• One screen, one job. A form, a list, a status. The cheapest useful software there is.
• Records created, listed, edited. The bread and butter of internal tools.
• Emailing somebody when something happens.
• A simple export. A CSV is fine and costs almost nothing.

Meaningful additions

• User accounts. Sign-in, passwords, resets, sessions, and "who is allowed to see what". Often the single biggest jump in a small build — and worth asking whether you need it. An internal tool behind one shared login is dramatically cheaper.
• Roles and permissions. Every role multiplies what has to be built and tested.
• File uploads. Storage, size limits, security, and what happens when someone uploads a 200MB video.
• Dashboards. One well-chosen number is cheap. "A dashboard" is a project, because deciding what to show is the expensive part.
• Integrations. Each external system is its own small project: its rules, its failures, its changes without warning. Budget per integration, not per project.

Expensive, and worth being deliberate about

• Taking payments. Not the payment itself — the refunds, failures, disputes, receipts, tax and reconciliation around it.
• Anything holding other people's personal data. Security, retention, access, deletion. Real obligations with real consequences, and the right place to spend money.
• Mobile apps. A website that works properly on a phone is a fraction of the cost of an app in two app stores. Most "we need an app" conversations end at a good mobile web page.
• AI features. Easy to add, hard to make dependable, and they carry a running cost per use. The honest question is whether the feature needs a model or whether a rule would do — a rule is cheaper, explainable and doesn't invent things.
• Offline, real-time, or multi-tenant anything. Each of these changes the architecture rather than adding to it.

The costs that aren't the build

Where budgets actually go wrong. The build is the part people plan for.

• Hosting and infrastructure — monthly, modest for a small internal tool, and non-optional.
• Maintenance — dependencies update, browsers change, things break. Plan for something like 15–25% of the build cost a year, and spend it.
• Changes — the ones you'll want in month three, once real use has taught you what's wrong. This is the most predictable cost in software and the least budgeted.
• Support — who answers when it stops working, and how fast.
• Your own time — deciding, testing, answering questions. Real, and unavoidable, and worth putting in the plan.

What I charge

Custom software, dashboards and automation projects start at $3,000. That is a starting point, not a price: every custom project is scoped and quoted on what it actually involves, and you get that quote in writing before anything begins.

Two honest notes on that figure. It's below the market ranges above because it describes a different thing: one builder, scoping the smallest useful version of one process, not a team delivering a platform. And it is a floor, not an average — a project with accounts, payments and three integrations is not a $3,000 project and I'll say so at the start rather than at the end.

If what you're describing is really a website with a form on it, that's cheaper again and it's on the packages page. I'd rather sell you the smaller thing.

a quote you don't understand isn't a quote. ask what each line is for.

How to make it cost less, properly

Not by negotiating. By wanting less, first.

1. 01Define the smallest useful version. Not the smallest version — the smallest one that removes the worst part of the problem. If it doesn't do that, it's a demo and you'll never use it.
2. 02Cut everything that isn't the one thing. Reporting, settings screens, admin areas, a second user type. Later, if the first thing earns it.
3. 03Skip accounts if you can. Internal tools often don't need them. This alone can change the shape of a quote.
4. 04Start with one integration, or none. Import a file by hand for a month. It's free, and you'll learn whether the integration is worth building.
5. 05Use boring, bought infrastructure. Nobody should be paying you to build a login system or a payment processor from scratch.
6. 06Write the rules down before you ask for a quote. Ambiguity is priced as risk. A clear one-page description genuinely lowers quotes, because it lowers the unknown.
7. 07Agree what happens when scope changes. Before it does. It will.

What to expect from a quote

A quote you can trust is specific about what's in it and specific about what isn't. Ask for:

• What's included, screen by screen or process by process
• What's explicitly excluded, in writing
• What happens if scope changes, and how that's priced
• What it will cost to run, monthly, after launch
• Who owns the code, and what happens if you part ways
• Whether you can host it yourself later
• What maintenance covers, and what it doesn't

Be suspicious of a fixed price for a vague description — somebody is going to be disappointed, and the mechanism is usually that the scope quietly shrinks. Be equally suspicious of "we'll see how it goes" with no ceiling.

The honest summary

Small internal tools that fix one annoying process are much cheaper than people expect. Applications with accounts, payments and integrations are much more expensive than people expect. The same idea can be either, depending entirely on where you draw the line — and drawing that line is the most valuable hour of the whole project.

Which is why I'd rather have the scoping conversation before talking about money at all. Usually it makes the number smaller. Sometimes it ends with "you don't need this built", and that's a good result too — more on that here.