Shipping Is Not Finishing
The moment a software product goes live, its costs change shape. Before launch, spending is lumpy and visible: engineers, design, infrastructure setup, maybe a few months of AWS bills during development. After launch, the spending becomes continuous, quieter, and far easier to underestimate. This is where most founders, and many experienced product managers, get into trouble.
The conventional wisdom is that software is cheap to maintain once built. The conventional wisdom is wrong. What changes after launch is not whether you’re spending money, but whether the spending is legible. Development costs show up in salaries and invoices. Maintenance costs hide in oncall rotations, dependency updates, security patches, and the slow accumulation of technical decisions that someone eventually has to revisit.
Understanding the real post-launch cost structure isn’t an accounting exercise. It’s a survival skill.
The Three Buckets Most Budgets Ignore
Post-launch software costs fall into three categories, and most financial planning only accounts for one of them clearly.
The first is infrastructure. This one at least shows up on a bill. Compute, storage, bandwidth, managed services, monitoring tools, CDN costs. These scale with usage in ways that are often non-linear, and the surprises tend to come not from normal growth but from traffic spikes, data retention requirements, and the creeping cost of services you enabled during a hackathon and never turned off. Cloud cost management is now its own industry for a reason.
The second bucket is security and compliance. This is where underestimation gets expensive. A product that handles user data needs to stay current with dependency vulnerabilities. The Log4Shell vulnerability in late 2021 forced engineering teams across thousands of companies to drop everything and patch, regardless of whether they had planned for that work. SOC 2 certification, if your customers require it, costs real money in both tooling and engineering time. GDPR compliance isn’t a checkbox you tick at launch and then forget. These costs don’t announce themselves in advance.
The third bucket is the one almost nobody budgets for explicitly: the cost of external change. Your product doesn’t exist in isolation. It depends on APIs, libraries, operating systems, browser standards, mobile platforms, and cloud provider services that all evolve on their own schedules. Apple changes how push notifications work. Stripe deprecates an endpoint. A major dependency drops support for the Node version you’re on. None of this is your fault, and all of it requires your time. Some teams spend ten to twenty percent of their engineering capacity just keeping up with changes they didn’t initiate.
The Human Cost Is the Biggest Line Item
Above all of this sits the cost that dwarfs the others: people.
A product that’s live needs someone watching it. Not necessarily full-time, but consistently. Alerts need acknowledgment. Bug reports need triage. Support tickets need answers that sometimes require an engineer to investigate. Even a product with excellent uptime and a small user base requires ongoing human attention, and human attention is priced in salaries.
The trap that catches small teams is the assumption that a stable product needs less engineering time than a product in active development. In practice, stability requires maintenance, and maintenance is work. The ratio shifts, but it doesn’t drop to zero. Many experienced engineering leaders estimate that a live production system demands somewhere between twenty and thirty percent of the effort that building it originally required, annually, just to stay current and operational. That’s not enhancements. That’s not new features. That’s staying in place.
For a startup that built its product with a five-person engineering team over twelve months, that math suggests you need at least one to two engineers doing nothing but keeping the lights on, indefinitely. If your financial model didn’t account for that headcount post-launch, your runway calculation is off.
Why Technical Debt Is a Maintenance Tax
Technical debt compounds. This is not a metaphor; it’s a mechanical description of how software systems age. Every shortcut taken during development becomes a constraint on future maintenance. The quick fix for a performance problem becomes the bottleneck you can’t touch when traffic grows. The hard-coded configuration that seemed reasonable becomes the source of the 2am incident three years later.
The relationship between technical debt and maintenance cost is direct and underappreciated. Teams that delete dead code and keep their codebase clean pay less to maintain it. Teams that ship fast without cleaning up pay a maintenance premium, indefinitely, until they either refactor or the product dies.
This is the hidden cost structure that makes acqui-hires complicated. When a larger company buys a startup for its team rather than its product, one reason is often that the product’s maintenance burden is already too high to justify keeping it running. The code is a liability, not an asset.
What a Realistic Post-Launch Budget Looks Like
There’s no universal number, but there are better frameworks for estimating. A useful heuristic used by experienced engineering managers is to plan for annual maintenance costs at roughly fifteen to thirty percent of the original development cost. A product that cost half a million dollars to build should be budgeted at seventy-five to a hundred and fifty thousand dollars per year just to maintain, not including new feature development.
That range varies based on several factors: how many external dependencies the product has, whether it operates in a regulated industry, how aggressively technical debt was managed during development, and how quickly the underlying technologies it relies on are evolving. A product built on stable, well-maintained open source components in a low-regulation industry sits at the low end. A fintech product built during a rapid development sprint on multiple third-party APIs sits at the high end.
Founders planning raises should build this into their models explicitly. Investors reading those models should ask about it directly. The question isn’t just “how long will this round last us?” but “how long will this round last us after we ship, given the cost of keeping what we built alive?”
The product doesn’t end at launch. The budget shouldn’t either.
