Software Is Never Really "Done": Why Custom Software Is a Going Concern, Not a One-Time Investment
Ask most companies when a software project is finished, and the answer is "when it launches." That instinct is understandable — it's how a lot of other business purchases work. You buy equipment, it arrives, it's yours. Custom software doesn't behave that way, and budgeting for it as though it does is one of the more consistent, avoidable mistakes companies make.
A Launch Date Is a Milestone, Not a Finish Line
The moment software goes live is the moment it starts encountering the actual business it was built for — real users, real edge cases, real changes to how the company operates that nobody could fully anticipate at the spec stage. A business that was stable when the project started six months ago has, by launch, usually already changed in some way: a new regulation, a new product line, a process the team discovered doesn't quite match how they actually work. None of that is a failure of the original build. It's just what happens when software meets an operating business instead of a museum piece.
Treating the launch date as "done" means the budget conversation stops exactly when the software starts generating the requests that actually matter — the feature that's now obviously missing, the workflow that needs adjusting, the integration a new vendor requires. A company that didn't budget for this finds itself in an uncomfortable position: the project is officially "delivered," so asking for more funds feels like admitting the original scope was wrong, even when it wasn't. That's the quiet failure mode — not a dramatic budget blowout, but a company that quietly stops asking for the improvements it actually needs because there's no clean mechanism left to fund them.
What "Going Concern" Actually Means Here
The accounting term is useful here even outside its usual context: a going concern is something expected to keep operating and generating value indefinitely, not something that gets used up and replaced. Custom software built around how your business actually works is exactly that — an asset that keeps paying off as long as it keeps getting the attention a real asset needs. Treated instead as a one-time purchase, the same software becomes something that quietly falls behind the business it was built for, one un-budgeted change request at a time.
This isn't an argument for padding every project with an indefinite maintenance retainer nobody asked for. It's an argument for budgeting the reality of the software's life honestly from the start: a build phase, followed by an ongoing phase that includes both keeping the lights on (bug fixes, security patches, infrastructure) and genuine enhancement (the features and adjustments a business inevitably needs as it changes). Even in an AI-native delivery model, where regenerating a feature is fast and often inexpensive, "fast and inexpensive" isn't "free," and a company that budgets zero for it is still going to run into the same wall eventually.
What This Looks Like Done Well
The companies that handle this well share one habit: they treat the post-launch phase as a planned, funded part of the engagement from day one, not an emergency conversation that happens later. That means agreeing upfront with your vendor on what ongoing support actually covers, what counts as a "mini project" versus routine maintenance, and — critically — having a real, pre-agreed path to request net-new funds for enhancements, rather than discovering after delivery that there isn't one.
Custom software is never really done, because the business it serves isn't done changing either. Budgeting for that reality upfront is the difference between an asset that keeps compounding in value and one that quietly stops being useful the first time it needs to grow with you.
If your current software has started feeling like something you're just maintaining rather than something that's still working for you, let's talk about what a realistic ongoing plan actually looks like.
Comments