What does custom software actually cost?

Every agency page that answers this question either gives you a range so wide it is useless, or a number designed to get you on a call. We are not going to do either, because we cannot price your project without seeing it and neither can anyone else.

What is genuinely useful is knowing what moves the number. If you can describe your project against the six factors below, you can predict roughly where a quote will land before you receive one, and you will be able to tell whether the person quoting has understood you.

One: how many kinds of user are there?

This is the single biggest multiplier and the one most often underestimated. Each distinct role is a set of screens, a set of permissions, and a set of edge cases where roles interact. An admin who can do everything a user can, plus three things more, is not one and a bit roles. It is two.

A single-role tool and a four-role platform with the same feature list are different projects by a wide margin. When you describe your product, count the roles first.

Two: how many other systems must it talk to?

Integrations are where estimates go wrong, because the work is rarely in the integration itself. It is in the other system: its documentation, its rate limits, its sandbox, whether it has a sandbox, and how long it takes to get credentials from whoever owns it.

One well-documented modern API is a known quantity. One internal system whose owner has left the company is an unknown that can outweigh the rest of the build.

Three: does it need to work offline?

Offline is not a feature. It is an architecture. It changes how data is stored, how conflicts are resolved when two people edit the same thing on two disconnected devices, and how you test any of it.

If your users are in a warehouse, on a trail, in a basement or on a plane, say so in the first conversation. Retrofitting offline support is close to a rewrite of the data layer.

Four: what state is the existing data in?

If you are replacing something, the data comes with you, and it is never as clean as the person describing it believes. Duplicate customers, three date formats, a free-text field that six people used six different ways, records that reference other records that no longer exist.

Migration is often a larger line than the feature it enables. A useful early test: ask whoever knows the data best how many customers you have, then ask the database. If the two numbers differ, budget for it.

Five: what is the compliance surface?

Handling payments, health data, children’s data, or anything in a regulated sector adds work that is invisible from the outside: audit trails, retention rules, access controls, penetration testing, and the documentation that proves all of it.

This is not a reason to avoid building. It is a reason to name it early, because compliance discovered in month four changes the architecture.

Six: who maintains it afterwards?

Software that will be handed to an in-house team costs more to build than software the original team will keep running, because the handover has to be real: documentation, a deployment anyone can run, and code written for a stranger.

That extra cost is worth paying and it is usually cheaper than the alternative, which is discovering the gap in a year. See the Second Version Test for what a real handover has to include.

How a quote should be built

A figure produced before anyone has looked at the problem is a guess with a decimal point on it. The way to get a number you can take to whoever approves budget is to pay for a small piece of scoping work first, and get a written description of the release specific enough to disagree with.

• A scope should name what ships and, more usefully, what does not.
• It should name the technical constraints that will shape the build, including the ones you did not know about.
• It should be yours to keep, whether or not you continue with whoever wrote it.
• It should be honest enough to tell you when the project is not worth doing.