What actually drives the cost of custom software?
Not the feature list. Effort scales with the number of distinct user roles times the number of states a record can be in, plus one hard multiplier for every external system you have to talk to. Data migration, permissions, and exception handling routinely consume more effort than the features people describe in the first meeting. The largest variable of all is how fast the client side makes decisions.
Features are the cheap part
People estimate software by counting features, because features are what they can see. But a feature is usually a screen and a save button. What surrounds it is where the effort goes: who is allowed to see it, what happens when two people edit at once, what the record looks like when it is half finished, and what the system does when the save fails.
A useful mental model is roles times states. Three user types and five statuses is not eight things, it is fifteen combinations that each need a defined behavior. Add a fourth role and you added five more.
The multipliers worth knowing about
- External systems. Every integration adds not just the connection but the other system's failure modes — rate limits, partial outages, schema changes, permission scopes. You are buying a share of someone else's operations.
- Data migration. Moving records is trivial. Reconciling duplicates, missing required fields, and history that does not fit the new model is not.
- Permissions. A tool where everyone sees everything is dramatically simpler than one with location-level or role-level visibility. Decide this early; retrofitting it touches every query.
- Real time versus scheduled. "Live" is a different architecture than "refreshed hourly," and most business questions do not need live.
- Exceptions. The main path is usually a small share of the work. The other cases — cancellations, reschedules, partial payments, the customer who is also a vendor — are the rest.
The driver nobody budgets for
Decision latency on the client side moves timelines more than anything technical. A build waits on API credentials, on a sandbox account, on someone deciding what counts as a qualified lead, on a review that takes two weeks because the reviewer travels. None of that is engineering time, but all of it is calendar time.
If you want a project to go faster, name one decision maker who can answer questions within a day and give the team direct access to the systems on day one. That single change usually outperforms adding people.
How to get an estimate you can trust
Ask for the estimate to be broken into the parts above rather than a single number. A partner who can tell you which piece is uncertain and why is describing a real plan. A partner who quotes a flat figure for a poorly defined scope is either padding heavily or about to run a change-order business.
The most honest structure is usually a short paid discovery that ends with a written architecture, a data model, an integration inventory, and a phased scope. That artifact is useful even if you then take it elsewhere. It is the same groundwork any serious integration project requires, and it is what turns a wish list into something a team can actually build — see how we scope work.
Topics: scoping · estimation · effort · complexity
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.