Budgeting for Software After It Launches
What to budget for once a software system is live, from security updates and hosting to staff time, and how to plan for it before the build is approved.
Most software budgets are built around the project itself: design, development, testing, and deployment. That part usually gets scrutinized carefully, as it should.
Everything after launch gets less attention. Once a system goes live, a second set of costs begins. They are smaller month to month, but they continue for as long as the system runs, and they fall into a few groups.
Security updates
Every application depends on libraries, frameworks, an operating system, and outside services, each of which publishes security fixes on its own schedule. Someone has to read the release notes, update the dependency, run the tests, and deploy. The work is routine, and putting it off moves the cost to a worse moment.
Hosting and outside services
Hosting, monitoring, backups, certificates, domains, and third-party subscriptions all recur. I would watch the usage-based ones most closely, because their bills rise as more people use the system. An AI feature or data pipeline that looked inexpensive during a pilot can cost considerably more once it is rolled out across an organization.
Changes you don’t control
Browsers and phone operating systems update. Vendors retire API versions, and model providers retire models. Each change takes some engineering time to absorb, and it arrives on the vendor’s schedule.
Keeping knowledge current
Documentation drifts out of date, and eventually the person who understood the tricky part of the system moves on. Paying someone to stay familiar with the system during quiet months costs much less than paying for a small problem to be rediscovered from scratch.
New features
Users will ask for changes, some small and some not. I would keep this line separate from maintenance in the budget. Otherwise feature requests tend to use up the hours that were meant for security updates.
A few habits that help
- Ask for an estimate of operating costs before approving the build. Even a rough figure is useful.
- Fund maintenance as a recurring amount. A reserve that only gets touched when something breaks tends to lose out to other priorities.
- Review usage-based costs monthly during the first year, since that is when unexpected growth usually shows up.
- Keep a short list of dependencies and their end-of-support dates, so replacements can be planned.
- Write documentation and handoff into the original contract as deliverables.
Steady, modest maintenance usually costs less over a system’s life than neglect followed by a rescue. When we deliver a system, we include an outline of what it will take to operate, so the second budget can be planned from the start.
