- Benchmark: plan on roughly 15–25% of the original build cost per year for maintenance. It is a rule of thumb, not a quote.
- Two buckets: tool and hosting bills can be priced from public pages, but usage charges make them grow. People's time (patching, fixes, small changes) has to be estimated with your team.
- Year two is not year one: growth can push you off free tiers, so budget for tool bills to rise as the product succeeds.
Software maintenance cost after launch is the money you spend each year to keep a live product secure, working and useful: hosting, monitoring, third-party services, dependency updates, bug fixes and small improvements. A common benchmark from a general software engineering reference puts it at 15–25% of the original development cost per year. For a founder, that means a build is not a one-time purchase. It is a purchase plus a running cost.
This article breaks that running cost into parts you can estimate, shows list prices for common tools, and gives you a simple way to set a year-two budget.
The 15–25% benchmark, and how to use it
The same reference says maintenance may account for 60–80% of total software lifecycle cost, often around 75%. It also notes that development takes 1–2 years while maintenance can continue for 15–20 years. Treat these as general benchmarks. Your product, stack and user base will push the real figure up or down.
To apply the percentage, take what the build cost and multiply it by 0.15 and by 0.25. The two results are the low and high ends of a yearly maintenance range. It is a way to size a budget, not a price for any specific project.
The lifecycle figure matters more than the yearly one. If most of a product's total cost comes after launch, the maintenance plan deserves as much attention as the build quote.
What the maintenance line actually covers
Maintenance covers more than bug fixes. Four things sit inside the budget.
- Infrastructure and services. Hosting, database, auth, email, storage, app store fees.
- Monitoring. Error tracking and uptime so you hear about problems before customers do.
- Security and dependency work. Patching libraries, updating frameworks, rotating keys.
- Fixes and small changes. Bugs, edge cases, copy changes and minor features users ask for early.
Security and dependency work is where the CISQ 2022 report is most relevant. It focuses on cybercrime losses from software vulnerabilities, software supply chain problems (especially open-source components) and technical debt. Those are the recurring patching and dependency tasks a maintenance line has to cover. The same report estimates the cost of poor software quality in the US at at least $2.41 trillion, with accumulated technical debt of about $1.52 trillion. That is an industry-wide figure, not your bill, but it shows the scale of the problem.
The tool bill: what it looks like in list prices
Infrastructure cost is the part you can price from a public page. The examples below are common choices for a modern web product. They are not recommendations, and your stack may differ.
| Item | List price | What to watch |
|---|---|---|
| Apple Developer Program | 99 USD per membership year (varies by region) | Fixed annual fee for any iOS app |
| Vercel Pro (hosting) | $20 per user per month billed annually, or $24 monthly | The seat buys a $20 usage credit, not unlimited use |
| Supabase (database and auth) | $0 Free, $25 per org per month Pro, $599 per month Team | Real production bills typically run $35 to $200 per month |
| Sentry (error tracking) | $26 per month Team, $80 Business (billed annually); free Developer plan | Cost rises with error volume |
| Datadog (infrastructure monitoring) | Free up to 5 hosts, then $15 per host per month (Pro, annual) | APM and logs are priced separately |
Sources: Apple, Vendr on Vercel, CloudZero on Supabase, Zapro on Sentry, UsagePricing on Datadog.
The seat price is the starting point, not the bill
Vercel Pro includes 1 TB of bandwidth, 1,000 GB-hours of serverless execution and 6,000 build minutes per month. The $20 seat buys a $20 usage credit, not unlimited use. A cost guide from ComparEdge lists compute overage at $0.128 per hour and fast data transfer at $0.15 per GB. SAML SSO is $300 a month. If a customer asks for single sign-on, that is a line item you did not have in year one.
Supabase works the same way. Paid plans add usage charges for compute, egress, storage and monthly active users, so production bills typically run $35 to $200 per month rather than the $25 headline.
Why products leave the free tier
Supabase Pro raises each database from 500 MB to 8 GB and auth from 50,000 to 100,000 monthly active users. It also removes the seven-day inactivity pause and adds daily backups. These are the features that push a live product off the free plan.
One more detail, from a pricing guide on we.inc: Supabase's spend cap is on by default, so going past a quota pauses that item instead of billing you. That avoids a surprise invoice, but it can turn into an outage. Decide which one you would rather have, and set an alert before you hit the limit.
Monitoring cost scales with volume
Sentry is a good example. A team sending 50,000 errors a month pays $312 a year on Team at list price. At 100,000 errors it pays $529.50. Doubling the volume does not double the cost, but it does grow it.
Datadog scales per host. Infrastructure monitoring is free for up to 5 hosts, then $15 per host per month on Pro (annual) and $23 on Enterprise. APM is $31 per host per month and log management is $0.10 per GB ingested. A competing observability vendor's analysis says a 50-host Kubernetes team running infrastructure monitoring and APM pays at least $2,300 per month before logs, custom metrics or real user monitoring. That source has a stake in the comparison, so check it against Datadog's own pricing page. The arithmetic does hold: 50 hosts at $15 plus 50 hosts at $31 is $2,300.
Count your hosts before you estimate. Per-host pricing means the bill follows your infrastructure, not your user count.
The people cost has no price list
Tool bills are the part with a public price. The rest is the time of someone who knows the codebase: updating the framework, reading error reports and fixing bugs. The benchmark is a share of build cost, not a list of subscriptions, so your budget needs a line for this work as well. When you compare quotes, ask who does this work and how fast they respond, and ask for a plain answer on ongoing work before you sign.
How to budget year two
Year two can look different from the first months. Usage has grown, and the tools you picked may charge differently as it does. Here is a simple way to set the number.
- Start with the benchmark. Take 15–25% of the original build cost and pick a point in the range based on how complex the product is.
- List your tool bills at list price. Add every service from the table that you actually use, then add a margin for usage overage, since the seat price is not the full bill.
- Model one growth step. Ask what changes if your users double. Which plan do you move to? Which cap do you hit?
- Reserve time for the unexpected. Keep part of the budget for a dependency that breaks or a security patch.
- Separate maintenance from new features. New features are a growth budget. Mixing them hides the true cost of keeping the product alive.
If you are still deciding what to build, the project planner helps you scope it before you commit to a number. For the build itself, our software development page explains how we work.
Questions to ask any team before you sign
- What does the first year after launch cost, in tools and in time?
- Who is on call when something breaks, and how quickly do they reply?
- Which of these services will I move off a free plan, and when?
- Do I own the code, accounts and credentials?
If you want help estimating the budget for your own product, get in touch.
FAQ
How much should I budget for software maintenance each year?
A common benchmark is 15–25% of the original development cost per year. Use it as a starting point, then check it against your actual tool bills and the people time the product needs.
Is maintenance more expensive than building the software?
Over the whole life of a product, often yes. The same benchmark reference says maintenance may account for 60–80% of total lifecycle cost. It also notes that development takes 1–2 years while maintenance can continue for 15–20 years.
Can I run my product on free tiers to save money?
For a prototype, yes. For a live product, check the limits first. On Supabase, for example, Pro raises database size from 500 MB to 8 GB, removes the seven-day inactivity pause and adds daily backups. If you hold real customer data, those backups are a reason to pay.
What can make the bill grow in year two?
Usage-based billing. Seat prices look fixed, but bandwidth, compute, egress and error volume are charged as you grow, and a request like SSO can add a line item, such as $300 a month on Vercel. Set alerts, and decide whether you would prefer a spend cap that pauses a service or a bill that keeps growing.
