Photo: Google Gemini · AI-generated
Most software budgets have a shape: a large number for the build, a small number for “support”, and a launch date in the middle that looks like the finish line.
The real shape is close to the opposite. For business software that stays in service for years, the initial build is a minority of the total lifetime effort. Everything after launch — patching, adapting, extending, keeping it compatible with a world that keeps moving — is the majority. Budgeting as if launch is the end is not optimism. It is a plan to be surprised.
The ground moves under working software
Here is the part that catches teams out: software does not decay on its own. Its environment changes around it, and the software has to keep up.
Operating systems get new versions with new rules. App stores change what they accept. Dependencies get security advisories that must be patched within days, not quarters. Browsers drop support for something you relied on. And the frameworks themselves move — sometimes decisively. Our Subcontractor Portal runs native apps on iOS, Android, and Windows, built with Xamarin and MAUI. Anyone who has shipped in that ecosystem knows what that sentence contains: Xamarin reached end of life, and MAUI is its successor. Applications built on it had to move — not because anyone asked for a new feature, but because standing still was not an option.
None of that work appears in a launch budget. All of it is mandatory.
The second half: the requirements you could not have known
The other driver is more welcome. Software that people actually use generates change requests, because using it teaches the business what it really needs.
The Subcontractor Portal is a good example again: a construction company coordinating hundreds of subcontractors across web and three native platforms, with offline-first field use and a delivery pipeline running dev, QA, test, and live environments through Azure DevOps. A system with that surface area does not stand still for a year. Sites change how they work, and the portal follows them. That is not scope creep. It is the system staying useful — which is the only reason it was built.
Support is not “waiting for something to break”
The word “maintenance” undersells this badly. It sounds like a helpdesk with an inbox. In practice, ongoing ownership is active work: monitoring that catches problems before users do, dependency and platform upgrades on a schedule, regression testing before every release, and someone who holds the context of why the system is built the way it is.
ReportSync shows why that continuity matters. It moves water-quality reports from the field into a company CRM, with full sync logging so delivery can be proven. That guarantee is not a one-time achievement — it depends on a chain of moving parts staying intact: devices, certificates, the CRM, the tunnel between them. It runs under Managed Support & Maintenance because the promise it makes is a continuous promise, and someone has to be responsible for it continuously.
What to budget instead
Three practical changes:
- Plan the lifetime, not the launch. Ask what the system costs to own for five years, and make that number visible at the start — not discovered in year two.
- Fund platform upkeep separately from features. Framework migrations and security patches compete badly against visible new features. Give them their own line, or they will lose every quarter until something breaks.
- Keep the people who know the system. Context is the cheapest asset you have and the most expensive to rebuild. A team that has to relearn your architecture every year is paying for the same knowledge repeatedly.
The point is simple: the build gets you a working system on day one. Application support and maintenance is what makes it still be working — and still be worth having — on day one thousand.
If you have software in service and no honest number for what keeping it healthy costs, that is a good conversation to have.