The build decision gets made in a burst of excitement about what's possible. The maintenance conversation, if it happens at all, happens eighteen months later, usually as a complaint about how expensive the custom thing has quietly become.
Why maintenance gets skipped in the decision
Building something feels like a one-time project with a finish line. Maintaining it is an ongoing, boring cost with no obvious end point, and it's much harder to estimate honestly at the moment you're excited about shipping something new. Nobody budgets enthusiastically for maintenance.
What maintenance actually includes
Security patches on every dependency, forever. Updates when the platform it runs on changes underneath it. The specific knowledge of how it works, concentrated in whoever built it, and the risk that concentrates with them if they leave. None of this shows up in the initial build estimate, all of it shows up in year two.
The question that should be asked before building, not after
Who owns this in three years, specifically, by name, and what happens if that person isn't here anymore. If there's no real answer, that's not a reason to never build custom, it's a reason to price the maintenance honestly into the original decision, instead of discovering the cost later as a surprise.
Buying isn't maintenance-free either
To be clear, this isn't an argument for always buying. Vendor relationships carry their own version of this cost, price increases, feature deprecation, acquisition risk. The point isn't that buying avoids maintenance, it's that custom maintenance is easier to underestimate because it's less visible until it's already a problem.
What this changes in practice
Price maintenance as a real, ongoing line item at the moment you decide to build, not as an afterthought once it's already overdue. A build that doesn't pencil out once maintenance is priced honestly probably shouldn't have been a build in the first place.