COBOX
What Software Maintenance Costs After Launch (and How to Budget for It)
When a product launches, most of the budget has been spent and everyone is tired and pleased. Then, a few weeks later, a message arrives: the payment page is slow, an SMS provider has changed its rules, and someone wants a small change to the invoice layout. Welcome to maintenance.
It's the cost people forget to plan for, and it's rarely small. Software isn't a building you finish. It's closer to a vehicle: it runs, but only if somebody keeps looking after it. This article explains what that work consists of and how to budget for it sensibly.
What "maintenance" actually means
The word covers four different kinds of work, and mixing them up leads to confusing quotes.
1. Keeping it running
Servers, databases, backups, security updates, certificates, monitoring. This is the work that stops the product falling over. Most of it is invisible when it's done well.
2. Fixing what's broken
Bugs appear once real people use a product in ways the team didn't predict. Some are cosmetic. Some stop a customer paying. Fixing them promptly is part of looking after your reputation.
3. Keeping up with the world
Browsers update. Phone operating systems update. The libraries your product is built on release security patches, and sometimes stop being supported. Payment gateways, map services and messaging platforms change their rules and prices. None of this is optional if you want the product to keep working.
4. Improving it
Small changes and new features based on what you learn from users. Strictly speaking this isn't maintenance, but in practice it's often bundled with it, which is why it's worth separating in your budget.
A rough rule of thumb
A figure often quoted across the industry is that yearly upkeep tends to come to somewhere around fifteen to twenty percent of the original build cost. Treat that as a starting point for a conversation, not a rule. A simple internal tool may need less. A product with many integrations, heavy traffic or sensitive data will need more.
Also expect the first six months to be busier than the following ones. Launch is when the surprises arrive.
The parts of the bill
People's time
This is usually the largest part. It can be a monthly retainer for a set number of hours, a support plan with response times, or payment per task. Retainers are easier to plan around. Pay-per-task can be cheaper if little goes wrong, and painful if a lot does.
Hosting and infrastructure
Servers, storage, databases, email delivery, backups, a content delivery network. For a small product this might be modest. It grows with usage, so ask how the cost behaves when you have ten times as many users.
Third-party services
Payment gateway fees, SMS and WhatsApp messages, maps, AI services, error monitoring, analytics. Many are charged per use, which makes them easy to underestimate. List each one and estimate a monthly figure at your expected volume.
Licences and renewals
Domain names, SSL certificates where not free, app store developer accounts (these renew every year), and any paid libraries or design tools.
Security and compliance
Periodic security reviews, access audits and, for some sectors, compliance checks. If your product holds customers' personal or financial information, plan for this from the start.
What happens if you skip it
Nothing, at first. That's the trap. Skipping upkeep feels fine for several months. Then one day a certificate expires and the site shows a warning, or a security flaw in an old library is exploited, or a phone update breaks the login on half your customers' devices. At that point you pay for emergency work, usually at the worst moment and at a higher rate.
There's a slower cost too. Neglected software becomes harder to change. Each month without updates makes the next upgrade bigger. Eventually the choice is between an expensive rescue and a rebuild. We cover that situation in how to modernise old business software without disrupting operations.
How to plan for it
- Ask for it in the proposal. A good quote includes a section on post-launch support, even if it's a separate line. If it's missing, ask.
- Separate fixing from building. Agree what's covered (bugs in what was delivered, for a set period) and what's new work.
- Agree on response times. Not every problem is urgent. Define what "urgent" means, such as customers can't pay, and how quickly someone will respond.
- Keep a small reserve. Hold back some of the budget, many founders aim for a quarter, for changes once real usage begins. It's also covered in mistakes founders make before building their first product.
- Review once a year. Look at what you paid for, what was used, and whether the arrangement still fits.
In-house or outsourced?
If you have a technical team, they'll likely handle day-to-day upkeep. If you don't, hiring one person to look after a small product can cost more than a retainer with a firm that spreads the work across several customers. Many businesses use a mix: an external team for infrastructure and security, and an internal person for small content or workflow changes.
Whichever route you choose, make sure the documentation and accounts are in your hands. There is a full checklist in who owns your software.
Questions worth asking your vendor
- What does your support plan include, and what doesn't it?
- How quickly will you respond to a serious problem?
- How are security updates handled, and who decides when to apply them?
- What do you monitor, and how will I find out if something goes wrong?
- What happens to my data and backups if we part ways?
The short version
Budget for the life of the product, not just the launch. Expect upkeep to cost a meaningful fraction of the build every year, separate it from new features, and put it in writing before you start. It's much less painful as a line in the plan than as a surprise in month eight.
If you'd like to see how we structure ongoing support, take a look at our software maintenance page, or ask us for a plan that fits your product.