The cost is in the edges, not the features

Ask anyone what a custom system will cost and they will start from the features. It is a reasonable instinct: the features are the part you can describe, demonstrate and get excited about. It is also why estimates and outcomes diverge so consistently, and the divergence has a shape.

A feature list describes the states you want the system to be in. Almost all the engineering is in the states you do not want it to be in, and those do not get written down because nobody wants them.

Five categories that eat budgets¶

Five categories of edge work recur across projects that otherwise have nothing in common. None of them shows up in a demo, and all of them are visible in advance if somebody asks.

1. What happens when it fails¶

“Submit the order” is one line on a list. The work is: the submission that times out after the order was created but before the confirmation, the duplicate that arrives because somebody clicked twice on a slow connection, the partially-saved record, the retry that must not charge twice. Every one of those is a decision somebody has to make, and if nobody makes it deliberately the system makes it by accident.

This is why an experienced firm asks uncomfortable questions early. Not to be difficult; because “what should happen if this half-finishes” is a business question with a business answer, and it is much cheaper before the code exists.

2. Permissions, which are always bigger than they look¶

Everybody remembers to ask who can see this. The question that costs money is who can see this about whom. A regional manager sees their region; a regional manager covering for a colleague sees two regions for three weeks; a contractor sees one client’s records and not the client list; a former employee sees nothing but their name still has to appear on the work they did.

Those are not edge cases, they are the ordinary life of an organization, and they turn a permission flag into a model. Getting it wrong is not a bug you patch: it is either a data exposure or a system people work around, and the workaround is usually a spreadsheet, which is where you came in.

3. Migrating the data you already have¶

Every replacement project carries a decade of records written under rules that changed three times. Duplicate customers with slightly different names. A status field that was repurposed in 2019 and never renamed. Dates typed as text. A required field that was optional for the first four years.

None of that is anybody’s fault and all of it is your project’s problem, because a new system with a strict model has to accept records the old one accepted loosely. Treat the condition of your existing data as a discovery input rather than a task at the end. Finding out late does not add a line item; it reprices the schedule.

4. The other system, on the day it is down¶

Integrations are quoted against the happy path because that is what the documentation describes. The cost is in the rest: what your system does while the ERP is in its maintenance window, what happens to work created during the outage, whether the reconciliation is automatic or somebody’s Tuesday, and who finds out first when the two disagree.

A useful test: ask what the system does if the integration is unavailable for four hours. If the answer is that it will not be, that is not an answer about the integration, it is an answer about the estimate.

5. Reporting, which is a second system¶

Reporting arrives as a late line on the list and behaves like a separate project, because the shape that makes a system fast to write to is rarely the shape that makes it fast to ask questions of. Whether that means a few well-chosen queries or a genuinely separate read model is a design decision with a real cost attached, and it should be made when the budget is being set rather than in the last month.

What to do with this¶

Not to inflate your budget. The point is that these five are findable in advance, by asking, and a proposal that has visibly considered them is worth more than one with a lower number and no evidence of having looked.

When you compare quotes, compare what each one says about the edges rather than what each one says about the features. The features will be roughly the same on every proposal you receive, because you supplied them. The differences are entirely in the part you did not write down.