Ask Your Dev Team how they handle maintenance
Some developers don't maintain the code they write. Learn why maintenance matters, what to look for in a plan, and how to choose the right one for your stage.
Believe it or not, some developers don’t maintain the code they write.
Like we covered in issue 3, some developers won’t work on brownfield projects, and that can even include ones where they’re the author. So it’s really important that you understand your developer’s approach to maintenance before you start working with them.
No software is “bug free”
Maybe your developer tells you their code is “bug free.” Let’s dispel that right away.
While it is theoretically possible for software to be bug-free, in practice it is very difficult to achieve. Software is complex and typically involves many lines of code. Even if a software application is thoroughly tested and appears bug-free upon release, new issues can arise when used in the real world. Users encounter unforeseen scenarios or use the software in ways that were not anticipated.
Even if your developer is taking every measure to include rigorous testing, code reviews, and bug tracking, a new release of iOS may introduce breaking changes that you could have never predicted.
Why you need maintenance
Just like a house, a software project isn’t done once it’s built. A good maintenance routine will:
- Correct bugs or errors that emerge over time
- Address updates to the libraries and frameworks in use
- Tackle changes in security requirements
- Optimize performance as you add users, they add load to the system
Proper maintenance can help extend the lifespan of your software, reducing the need for frequent replacement and the costs of developing new software. This is an insurance policy for your investment.
Two things to ask about
1. Retainer vs. on-demand
Does your developer require a retainer, or can they perform maintenance on-demand?
Pay attention to their SLA (Service Level Agreement), which determines how quickly your developer will respond to issues. I’ve seen one business day for retainer hours (unless there’s a 24/7 support agreement) and no response guarantee for on-demand work.
Know what you need and make sure you pick a plan that works for your business.
2. Support model
This usually defines service windows, most commonly business hours and after hours. I’ve even seen a third window for holidays.
- On-call model: The developer is available at all times
- Best-effort model: Developers make their best effort to respond to incidents after hours. After-hours work is typically billed at 1.5x standard rates with a one-hour minimum.
What plan is right for you?
24/7/365 support
If you’re running an ecommerce store, serve a global audience, or your system performs scheduled tasks around the clock, this is the plan you need. If the cost of downtime is higher than the cost of keeping your developer on-call, it’s an easy decision.
Pre-revenue startups (under 100 users)
Don’t worry about immediate maintenance. Instead:
- Ask your developer to outline a scheduled maintenance plan covering security and server updates
- Plan a monthly meeting to review bug tracker issues, prioritizing them into must do, should do, and it can wait
- Give your developer freedom to correct anything that causes an application crash, but watch your budget
If you’re funded, spend your money on customer acquisition. If bugs are causing conversion or retention issues, address them, but consider that money spent on acquisition, not maintenance.
Scale-ups (seed to Series A)
If your software serves a global audience or runs constant tasks, on-call support is likely what you need. Otherwise:
- Discuss a retainer with your developer
- Confirm one-day response times during business hours
- Ask for a process to see issues as they come in and approve priorities
- Request incident reports on a regular cadence
What about leftover retainer hours? Don’t lose them. Make sure your developer’s maintenance plan covers server upgrades, improved testing, and keeping bug trackers up to date. Build a backlog of enhancements they can work on during downtime.
I hope this issue helps you keep your software in top working order. Go build something and expect better from your developer.