Maintenance Budgets: What to Expect After Launch

What you need to know

• The fifteen to twenty percent rule is the starting point: budget fifteen to twenty percent of the original build cost per year for maintenance of a stable product.
• Products with mobile apps, external API integrations, and compliance requirements have higher maintenance costs than products without.
• Infrastructure costs compound as usage grows. An infrastructure cost model that works at 1,000 users may not work at 100,000 without optimization work that has its own engineering cost.
• Dependency maintenance is not optional. Unpatched dependencies accumulate security vulnerabilities. The cost of a security incident far exceeds the cost of keeping dependencies current.
• The cost of deferred maintenance compounds. A backlog of unaddressed dependency updates and technical debt increases the cost of each subsequent maintenance cycle.

The core argument

The maintenance cost conversation that founders avoid is the one about ongoing infrastructure. A product launched on a cloud platform with a database, background job runner, email service, monitoring, and CDN has a monthly infrastructure cost that is independent of engineering time. This cost starts small and grows with usage. At 1,000 users, the infrastructure cost might be 200 to 400 dollars per month. At 10,000 users without cost optimization, the same infrastructure could cost 2,000 to 4,000 dollars per month, sometimes more depending on how the product was built. Infrastructure costs that were designed for a low-usage MVP do not scale gracefully.

Engineering time is the larger maintenance cost. The typical maintenance work cycle for a live SaaS product involves dependency updates every four to six weeks, security patches as they are released, bug fixes from production incidents, and the minor feature work that customer retention requires. For a solo founder with a contractor relationship, this translates to three to five hours per month at minimum for a simple product, and twelve to twenty hours per month for a product with active customers and complex integrations. The mistake is budgeting zero engineering time for maintenance after launch and treating the product as complete when it goes live.

Third-party API integrations are where maintenance costs surprise founders most. A product built on three or four external APIs inherits the maintenance burden of those APIs: when Stripe updates its API, when a data provider changes their authentication, when a payment processor deprecates a webhook event. These changes arrive on the external provider's timeline, not yours. In my experience working with products that have five or more external integrations, an average of one to two breaking integration changes per quarter is a realistic expectation. Budgeting engineering time for integration maintenance is not optional; it is the cost of using APIs you do not control.

Common mistakes

1. Treating the launch date as the end of the engineering cost. A live product with users requires ongoing engineering investment. The launch date is the beginning of the maintenance phase, not the end of the engineering phase.

1. Not tracking infrastructure costs against usage growth. Cloud costs that grow faster than revenue create a business model problem. Monitor cost per user or cost per transaction from the first month in production and set alerts when the ratio changes significantly.

1. Deferring dependency updates until a security incident forces them. Outdated dependencies accumulate. A product that has not updated dependencies for twelve months may have dozens of known vulnerabilities. Batch dependency updates monthly or use automated tools like Dependabot to keep the backlog manageable.

1. Not budgeting for mobile app store compliance updates. Apple and Google regularly change requirements for apps in their stores: new privacy permissions, updated API requirements, SDK version minimums. These updates are not optional and may require code changes on a schedule the store dictates.

1. Conflating maintenance cost with improvement cost. A maintenance budget covers keeping the product running and compliant. New features and improvements are a separate budget. Conflating them makes it impossible to know whether the product is profitable to operate.

Where to start

1. Audit your current monthly infrastructure cost and track it per active user. This gives you a baseline cost-per-user metric that makes infrastructure scaling costs predictable as the product grows.

1. Run a dependency audit on the product's main dependencies. Check for dependencies with known security vulnerabilities using npm audit, pip audit, or equivalent. Set up Dependabot or a similar tool to automate dependency update PRs.

1. Create a maintenance line item in your budget. Separate from new feature development, allocate a fixed number of engineering hours per month for maintenance: dependency updates, bug fixes from production, infrastructure optimization. This makes maintenance visible in financial planning.

Related reading

• How to Build a Twelve-Month Software Budget That Survives Reality
• How to Read AWS, Azure, and GCP Invoices Without Crying
• Hosting Cost Optimization: From Ten Thousand to a Million Users
• Tech Debt: The Real Cost and When to Pay It Down