Nobody asks about maintenance before they sign. Everyone panics about it six months after launch.
Custom software isn't a one-time purchase. It's a living system that needs hosting, security patches, bug fixes, performance monitoring, and ongoing development as your business evolves. The agency that built it won't maintain it for free. And if you don't have a plan, you'll find out the hard way — usually when something breaks on a Friday evening.
This post covers what software maintenance actually means, what it costs, and the three models for handling it. If you're about to commission a custom project, read this before you sign — not after you launch.
What "maintenance" actually includes
When people hear "maintenance," they think bug fixes. That's maybe 20% of it. The rest is less visible but equally critical.
Hosting and infrastructure. Your application runs on servers. Those servers need monitoring, scaling, backups, and occasional configuration changes. If you're on a managed platform like Laravel Forge or AWS, some of this is automated — but someone still needs to watch it.
Security updates. The framework, the programming language, the server operating system, and every third-party package your application depends on release security patches regularly. Applying them isn't optional. Ignoring them turns your application into a target. This isn't theoretical — unpatched dependencies are the most common attack vector for web applications.
Bug fixes. No software ships without bugs. Some appear immediately. Others surface weeks or months later when users encounter edge cases nobody tested. You need someone available to diagnose and fix these — ideally before your users report them.
Performance monitoring. Applications slow down over time as data grows, usage patterns change, and infrastructure ages. Without monitoring, you won't notice the slowdown until users complain. With monitoring, you catch it early and optimize before it becomes a problem.
Small feature requests. Your business changes. A new regulation requires an extra field. A team restructure means new user roles. A client asks for an export format you didn't plan for. These aren't new projects — they're the natural evolution of a living system.
Dependency updates. The framework releases a new major version. A third-party API you integrated changes its endpoints. A payment provider deprecates the SDK you're using. Keeping your application compatible with the world around it is ongoing work.
What maintenance costs
The industry standard is 15-25% of the original development cost per year. This is a useful benchmark, but it varies depending on the complexity of your application, the number of users, and how actively the business is evolving.
For a project that cost $100K to build, expect $15K-$25K per year in maintenance — covering hosting, security updates, bug fixes, monitoring, and minor feature work. That's roughly $1,200-$2,000 per month.
This number surprises many clients. But consider the alternative: if your application goes down for a day because nobody applied a security patch, or if you lose data because nobody was monitoring backups, the cost of that incident will exceed a year's worth of maintenance.
The cheapest maintenance is proactive maintenance. The most expensive maintenance is fixing something that broke because nobody was watching.
Three models for handling maintenance
Model 1: The agency retainer
You keep a monthly retainer with the agency that built the software. They handle hosting, monitoring, security updates, bug fixes, and small feature requests within the retainer scope. Larger feature work gets scoped and billed separately.
When this works: When you don't have an in-house technical team and want a single point of responsibility. The agency knows the codebase, knows the architecture decisions, and can respond quickly because they built it.
The risk: Dependency on the agency. If the relationship sours, or if the agency closes or reprioritizes, you need to transition — which is why code ownership and documentation matter so much at handoff.
This is the model most of our clients use with us. We offer monthly retainers that cover proactive maintenance (monitoring, updates, backups) plus a bank of hours for bug fixes and small changes.
Model 2: In-house team
You hire one or more developers to maintain the software internally. They handle day-to-day operations, bug fixes, and incremental feature development.
When this works: When the software is core to your business, when you have enough ongoing development work to justify a full-time hire, and when you can recruit someone with the right skills.
The risk: You need to find someone who can work with the existing codebase — which is why the technology choice matters. We've written about why we build on Laravel specifically because the talent pool makes in-house hiring realistic. Try hiring an in-house Elixir developer for a mid-sized company and you'll understand the problem.
If you're planning to go this route, make sure your agency delivers proper documentation, clean code, and a handoff session. Without these, your new hire will spend their first three months just understanding what was built.
Model 3: Nobody
You launch the software and hope nothing breaks.
When this works: It doesn't.
We've inherited projects from clients who tried this. The pattern is always the same: the application works fine for 6-12 months. Then a security vulnerability gets published for an unpatched dependency. Or the SSL certificate expires and the site goes down. Or the server runs out of disk space because nobody configured log rotation. Or a payment provider updates their API and transactions silently start failing.
The cost of "no maintenance" isn't zero — it's deferred. And deferred maintenance always costs more than proactive maintenance because you're now fixing a crisis instead of preventing one.
What to negotiate before you launch
If you're in the process of commissioning custom software — or about to sign with an agency — put maintenance on the table now. Not after launch. Here's what to clarify:
Who owns the code? You should. Full ownership, in a Git repository, with documentation. This ensures you can switch providers or bring maintenance in-house if needed. We've written about this in our post on how we deliver projects — code ownership is non-negotiable for us.
What does a maintenance retainer include? Get specifics. "Ongoing support" is vague. Does it include hosting? Monitoring? How many hours of bug fixes per month? What's the response time for critical issues? What's billed separately?
What's the response time commitment? If your application goes down at 2 PM on a Tuesday, how quickly will someone respond? This should be in writing, not assumed.
What happens if we outgrow the retainer? If your application grows significantly, the maintenance scope will need to grow too. Understand how the retainer scales — fixed annual price, or adjusted based on usage and complexity.
What happens if we want to leave? If you decide to switch agencies or bring maintenance in-house, what does the transition look like? A good agency will make this easy because they've already given you the code, the documentation, and the knowledge.
The maintenance conversation is a trust signal
Here's something we've noticed: agencies that avoid the maintenance conversation during the sales process are usually the same agencies that deliver undocumented code, resist handing over the repository, and create dependency by design.
An agency that brings up maintenance proactively — that explains the costs, offers clear retainer options, and ensures you can leave if you want to — is an agency that's thinking about the long-term health of your project, not just closing the deal.
Use this as a filter when evaluating agencies. Ask them: "What happens after you launch?" If the answer is vague, that tells you everything.
We've written about how to write a software brief, how pricing models work, and how long projects take. Maintenance is the final piece — the one that determines whether your investment keeps delivering value or slowly deteriorates.
Planning a project and want to understand the full lifecycle cost? Let's talk →