How Much Does Custom Software Cost?

Ask three developers what custom software costs and you'll get a shrug, a suspiciously precise figure, and a request for a call. The shrug is closer to honest than the precise figure — but neither helps you plan. What actually helps is understanding why the price moves, so you can read any quote you receive and tell whether it was built on your project or pulled from the air. That's what this guide covers. It contains no dollar figures, on purpose: any number we printed here would be a guess about a project we haven't seen, and guesses dressed up as answers are exactly the problem.

Why nobody gives you a straight number

"Custom software" covers an enormous range of work. A tool that replaces one spreadsheet for one person is custom software. So is a portal where customers log in, technicians update jobs from their phones, invoices sync to your accounting system, and the owner gets a nightly report. Both are real projects; they are not remotely the same size. Asking what custom software costs is like asking what a building costs — the answer for a carport and the answer for a clinic differ so much that a single number would be meaningless.

So when a developer won't name a figure before understanding your project, that's not evasion — it's the same reason a good contractor walks the site before bidding. The number depends on scope, and scope lives inside your business: how many people use the tool, what it connects to, what data comes with it. The honest sequence is understand first, price second. Be more suspicious of the developer who skips straight to the number.

What actually drives cost

Nearly every quote we've ever written comes down to six factors. If you understand these, you can predict which way a price will move before anyone tells you:

• User roles and permissions. One person using a tool is simple. The moment you add roles — owner sees everything, office staff see jobs and invoices, field crew see only their schedule — the software needs logins, permission checks on every screen, and testing for each combination. Every role multiplies the surface area.
• Integrations. Each outside system the software talks to — accounting, CRM, payment processor, scheduling tool — is its own mini-project: authentication, mapping your data to theirs, and handling the days that service is down or changes something. Two integrations aren't twice one; they can also interact with each other.
• Data migration. If years of history live in spreadsheets or an old system, moving it in takes real work: cleaning duplicates, reconciling formats, deciding what "customer" meant in 2019 versus now. Starting fresh is cheaper; keeping your history is often worth it — but it's a line item, not a freebie.
• Reporting. "Show me a list" is easy. "Show me margin by crew by month, filterable, exportable, emailed every Monday" is a feature set of its own. Reporting requirements often add as much work as the core tool.
• Custom logic vs. standard patterns. Login screens, forms, lists, and search follow patterns developers have built a hundred times. Your commission formula with seventeen exceptions has been built exactly zero times. The more your rules deviate from standard patterns, the more of the budget goes to logic that exists nowhere else.
• Polish level. An internal tool your own staff uses can be plain and still be excellent. A customer-facing product carries your brand, so it needs design attention, friendlier error handling, and behavior that holds up in the hands of strangers. Same function, different finish, different price.

The cost shape: build vs. maintain

Custom software has a distinctive cost shape: most of the money is up front, in the build, followed by a much smaller ongoing amount for support — hosting, backups, security updates, and small fixes as your business shifts. It's the shape of buying equipment: a real purchase, then upkeep.

Subscription software is the opposite shape: little or nothing up front, then a per-seat fee every month, forever, that typically grows as you add people. Neither shape is automatically better. But when you compare a custom quote to a subscription, compare shapes, not sticker prices — the honest comparison is the build cost plus a few years of support against the same years of subscription fees at your team's size, including the seats you'll add as you grow. Sometimes the subscription still wins; sometimes the compounding quietly reverses the answer. We walk through that whole decision in custom software vs. off-the-shelf.

One more thing an honest quote should show: ongoing support priced separately and stated up front. Software isn't a roof; it lives in a moving world of browser updates and security patches. A build price with no mention of what happens after launch is an incomplete price.

Cheap patterns vs. expensive patterns

Put the drivers together and you can see why two projects that sound similar in a sentence can sit at opposite ends of the range.

The inexpensive end looks like this: a single-user internal tool, no integrations, starting from a blank slate, standard screens — forms, lists, search — with plain-but-clean styling. Every cost driver is at its minimum. There's one role to build and test, no outside systems to negotiate with, no history to migrate, and the whole thing is assembled from patterns that already exist. This is also, not coincidentally, the kind of project we recommend most often as a first step.

The expensive end looks like this: a multi-role portal — customers, staff, admins — that syncs with three outside systems, imports a decade of records, and produces custom reports for each audience. Nothing on that list is exotic, but every driver is turned up at once: three-plus roles to secure and test, three integrations that each need building and babysitting, a migration project inside the project, and reporting as a second product. The two projects might get described in conversation with the same words — "we need a system to manage jobs" — which is exactly why nobody can price the sentence. The cost lives in the details underneath it.

How we price it

Since we can't print a universal number, here's the thing we can print: our actual process, the same one every Secret Systems software project goes through.

1. Discovery call. A conversation about the process that hurts — who does it today, what it touches, what "fixed" would look like. No charge, no obligation, and if off-the-shelf software would serve you better, this is where we say so.
2. Written scope. We put the project in writing: what the software will do, who uses it, what it connects to, and — just as important — what's explicitly out of scope. You can take this document to another developer for a competing bid. We'd rather you compare bids on the same scope than guess.
3. Written quote before any work. A fixed figure tied to that written scope, before anything is built. If the scope changes mid-project, the price conversation happens in the open, in writing, before the work — not on the final invoice.

Third-party costs — hosting, domain names, paid services the software depends on — are disclosed separately and billed at cost, so you always know which part of the money is ours and which passes through. That's the whole system. It isn't clever; it's just the order of operations that keeps surprises out.

How to budget without a quote

You can do useful budgeting before you ever talk to a developer — not by guessing a number, but by shrinking the problem until the number, whatever it is, gets small too:

• Name the one process that hurts most. Not the five things you'd like — the one that costs hours every week or loses you money when it goes wrong. That's the project. Everything else is a later phase.
• Define the smallest version that removes the pain. Fewer roles, fewer integrations, standard screens. If the pain is "quotes take two hours and live in Susan's head," the smallest version is a quote builder — not a quote builder plus scheduling plus invoicing plus a customer portal.
• Expand after it proves itself. Software built this way earns its next phase with results from the last one. Phase two gets scoped against a tool your team already uses, which makes it better-aimed and easier to price than a grand plan drawn up on day one.

This approach doesn't just keep the first check small. It keeps every check honest, because each one buys a working thing rather than a fraction of a promise.

Questions to ask any developer about price

Whoever you hire — us included — these questions belong in the first money conversation. Good developers answer them readily; the answers tell you what the number actually buys:

• What exactly is included in this price? Design, build, testing, deployment, training? Get it in writing.
• What is explicitly excluded? The scariest costs live in the gap between what you assumed and what they scoped. A developer who volunteers the exclusions is protecting you both.
• Who owns the code when it's done? You want to own what you paid for — or at minimum have the unconditional right to take it to another developer. "You'd have to keep paying us to use it" changes the entire economics.
• What does support cost after launch, and what does it cover? Bug fixes vs. new features vs. emergencies — where are the lines?
• What happens if the scope changes mid-project? The answer should involve a written change, priced before the work happens.
• Which third-party costs will I carry, and at what rates? Hosting and services should be disclosed, not discovered.

Red flags

A few pricing behaviors that should make you slow down, whoever you're talking to:

• A precise quote before anyone understood your process. If the number arrived before the questions did, it wasn't priced on your project — it was priced on getting your signature. That number changes later, and never downward.
• A price too good to include support. If a quote undercuts everything else you've heard, find out what happens after launch. Software with nobody on the hook for it doesn't stay cheap; it becomes a rescue project — often re-scoped from scratch by whoever inherits it.
• Hourly billing with no cap and no scope. Hourly isn't inherently wrong, but hourly with no written scope and no ceiling means you've agreed to a total nobody has said out loud. You deserve to know the worst case before work starts.
• Vagueness about ownership. If the answer to "who owns the code?" takes more than a sentence, assume the answer is "not you" until proven otherwise.

None of these automatically mean bad faith — sometimes they're just inexperience. But price problems announced this early rarely improve with time, and the fix costs nothing: keep asking until the answers are in writing. If you want to see how these questions play out on a real project — yours — our software development page covers what we build, and the discovery call is where the honest number finally gets to exist.