Estimate Before the Estimate: Sizing a Custom Software Budget on Your Own

You cannot know what a custom system will cost before someone has examined your environment, and anyone who offers a figure sooner is guessing. What you can know, on your own and in an afternoon, is which parts of your project will drive the cost and which of them you cannot yet describe. That knowledge is worth more than a number, because it lets you question a proposal's reasoning instead of staring at its total.

Why published price ranges do not help you

Search for the cost of custom software and you will find ranges so wide that a departmental tool and a company-wide platform both fit inside them. A range like that is not wrong. It simply carries no information about your project.

You will not find dollar figures in this article, on purpose. A printed number would be an average across projects that are not yours, and once you have read it you will measure every proposal against it. A model of what produces the number is more useful. With the model you can look at two quotes that differ by a factor of three and work out which assumption explains the gap.

The feature list is the wrong place to start

Most buyers describe a project as a list of screens and functions, and most first conversations with vendors go the same way. It feels natural, because features are what users will see.

The trouble is that features explain little of the variation between projects. Two systems with an identical feature list can differ enormously in cost because of what they have to connect to, what they inherit and what they must guarantee. I find it useful to sort the cost drivers into three groups.

Group one: what the system touches

Integrations. Count every system the new software must read from or write to. Then, for each, note the interface: a documented API, a file drop, direct database access, or nothing at all. Each connection brings the same chores: learning how the other system really behaves, handling its failures and timeouts, storing credentials safely, retrying without creating duplicates, and repairing the link when the other side changes. When the other side is an old system with no documentation and no test environment, the connection alone can end up pricier than whatever function required it. In my experience this is the most frequent reason an estimate turns out to be wrong.

Inherited data. If history has to move from an old system, the copying is the cheap part. The expense is in the records the old system tolerated: customers entered three times, dates stored as free text, required fields filled with a period, statuses nobody remembers the meaning of. The new system will have stricter rules, so each of those needs a decision. Until someone on your side can state the clean share of the existing records, you do not have a migration estimate yet. You have a profiling task.

Group two: what the system must guarantee

Compliance and audit. Regimes such as HIPAA and SOC 2 shape the design from the first day: how access is granted, what gets logged and for how long, how data is encrypted, how deployments are approved, which hosting services are allowed. When these rules are part of the first design, the cost is known and can be planned. Retrofitting them into a system that was built without them means reopening decisions already made, and that is much more expensive. (This is general information, not legal advice. Confirm your obligations with counsel.)

Uptime and correctness. Ask two questions. What does an hour of downtime cost the business? And what happens when the system shows a wrong number? An internal tool that can be offline on a Sunday morning needs one server and a backup. A system that takes orders around the clock needs redundancy, monitoring, tested failover and people on call. Similarly, a dashboard with a rounding quirk is an annoyance, while an invoicing error is a financial problem with its own controls, reconciliation and test burden.

Group three: what the system does

Distinct roles. Each kind of user with really different permissions and screens is close to another application to design, build and test. Five roles do not cost five times one role, but they cost a lot more than one, and the interactions between them (who can approve whose work, who can act on behalf of whom) multiply the test cases.

Features and interface. The number of functions and the polish of the interface do matter. They are just the driver that vendors estimate best and that surprises budgets least.

Ranked by their typical effect on the final budget, the six fall roughly in the sequence used above: integrations, data, compliance, guarantees, roles, features. That is a ranking from experience, not a measured result, and your project may reorder it.

Same features, different projects

Consider two hypothetical companies that both want a customer portal where clients log in, view orders, download invoices and open service requests.

Company A runs a modern cloud ERP with a documented API. Its customer records were cleaned up during a recent migration. No regulated data is involved. There are two roles: customer and internal staff. If the portal is down for an hour overnight, nobody is hurt.

Company B runs a 20-year-old ERP on a server in its own building, with a vendor that has stopped publishing documentation. Orders live there, invoices live in a separate accounting package, and service requests live in a third tool. Roughly a third of customer accounts are suspected duplicates. Some customers are healthcare providers and upload documents containing patient information. There are five roles, including a distributor who acts for several end customers. The portal is the main ordering channel.

The feature list is word for word the same. Company B's project is several times larger, and almost none of the difference is in the screens. If both companies collected quotes based on the feature list alone, Company B's quotes would be fiction.

A worksheet you can fill in before talking to anyone

Answer each line in writing. The score does not matter. The blanks do.

Every blank is something a discovery phase has to answer. With three or more lines blank, putting quotes side by side is premature, because the vendors will fill those blanks with their own assumptions, and each will fill them differently.

The last line matters most

The question about the smallest useful release deserves extra time. A team that can say "version one only handles reorders for existing customers, and that alone removes 40 calls a day" has a project that can ship early, earn trust and be stopped at any point with something in hand. A team that cannot name a smaller version will build the whole thing at once, and the whole thing is where overruns live.

It is also a check on whether you should build at all. If the smallest useful version looks exactly like a product you can already buy, buy it.

Reading a proposal when you cannot check the number

The total itself is beyond your power to check from the outside. The thinking that produced it is not.

Are the assumptions written down? A line such as "assumes the ERP exposes order data through a REST API with a test environment" is a gift. You can confirm it or correct it, and you know what happens to the price if it is false. A bare total gives you nothing to discuss.

Is investigation priced separately from construction? A firm price for a system the vendor has not looked inside can only mean one of two things: a large cushion built into the number, or a plan to reopen the price once the surprises arrive. You pay either way.

Does it say what is left out? The usual omissions are data cleanup, user training, third-party licenses and hosting, and support after launch. If the proposal is silent on these, ask about each by name.

Can you stop between phases? Phases should end at decision points where you hold something usable, not only at payment milestones. The first of those points should come right after discovery.

Does the estimate show its uncertainty? Early estimates are wide and should narrow as unknowns are resolved. A proposal that gives a tight number for the first phase and an honest range for later ones is showing you how estimation really works. One precise figure for a year of work is not more accurate. It is just hiding the range.

The part of the budget that starts at launch

Launch is where a second set of costs begins, and over the life of a system they commonly add up to more than the original build.

• Keeping it current. Frameworks, libraries and runtimes release security fixes and eventually reach end of support. Someone has to apply updates and test them.
• Repairing connections. The systems you integrated with will change their APIs. Each change is unplanned work on your side.
• Running it. Hosting, databases, monitoring, backups, third-party services and license fees recur every month.
• Watching it. If the uptime requirement is real, someone is on call, and that has a cost.
• Changing it. The business will change, and the software must follow. This is usually the largest item.

A plan that budgets nothing for the first year after launch produces a predictable result: the system drifts, falls behind on updates, and within a few years the conversation is about modernization. Ask every vendor what happens after go-live, who does it and what it costs.

Two things this model does not cover

Where the team is located changes the arithmetic through overlap hours, rework and coordination, in ways an hourly rate does not show. And none of this tells you whether a particular vendor can deliver what they describe. Both are separate evaluations, and both are worth doing before you sign.

Which of the six drivers can you not answer yet?

Send Trivo your blank lines. In a Two-Week Discovery we go through each driver against your real systems and data, and the written scope that comes out of it is yours to hand to whichever firm you choose, ours or another.