# The Maintenance Problem: Why We Include It
Software doesn't stay fixed after you ship it. Dependencies get outdated. Bugs surface in edge cases nobody anticipated. Security vulnerabilities are discovered in underlying libraries. The business requirements change. The infrastructure it runs on needs updates.
Maintenance is inevitable. The question is who pays for it, and how.
How Most Firms Handle This
The standard model in software development is to treat maintenance as a separate contract—a "support and maintenance agreement" that you negotiate after the project is done. Typically it's priced as a percentage of the original development cost, annually.
This model makes sense for the vendor. Maintenance is recurring revenue with relatively predictable costs. A client locked into a support agreement doesn't shop around when they need a bug fixed.
It makes less sense for the client.
You pay twice. You paid to build something, and now you pay again to keep it working. The maintenance contract often covers only reactive work—fixing things when they break—not proactive improvements that would prevent problems.
Incentives are misaligned. A firm that profits from fixing bugs has a subtle financial incentive to not spend too much energy preventing them. This is rarely conscious, but incentive structures matter.
The handoff creates risk. If the original team isn't maintaining the code, the firm doing maintenance is learning your system on your dime.
Why We Include It
We include maintenance in every engagement contract for three reasons:
It aligns incentives. When we're responsible for maintenance, we have a strong incentive to write maintainable code. Clean architecture, clear documentation, comprehensive tests—these are how you minimize maintenance burden. If we're doing the maintenance, we're motivated to do the upfront work that makes maintenance easier. If we're not doing the maintenance, that motivation is weaker.
It's honest pricing. The real cost of software is not just the development cost. It's development plus ongoing maintenance plus eventual updates and improvements. Separating these into distinct contracts creates an illusion of lower initial cost that evaporates over time. We'd rather give you an honest number upfront.
It builds better relationships. The clients we've kept longest are the ones where we're not just doing project work but are invested in the ongoing health of their software. That ongoing relationship gives us context that makes every new project faster and better. Treating every engagement as a one-time transaction loses that compounding value.
What "Maintenance Included" Actually Means
To be clear about what's covered:
Bug fixes. If we built it and it breaks, we fix it. No separate ticket, no estimate, no approval cycle. It gets fixed.
Security patches. Dependencies get security vulnerabilities. We monitor and patch them. This isn't optional—unpatched vulnerabilities are how systems get compromised—and we don't pass that risk to clients.
Compatibility updates. Operating system updates, browser changes, platform updates that affect your software are handled. Again, not optional if you want a system that keeps working.
Minor adjustments. Small UX improvements, copy changes, configuration adjustments—the everyday maintenance that every software system needs.
What's not included in maintenance: new features, significant refactoring, integrations with new systems. Those are scoped and priced separately. But the upkeep of what we built? That's on us.
The Math
Here's a simple model. A project costs $150,000 to build. A typical maintenance contract is 15-20% annually—call it $25,000/year.
Over three years, total cost: $225,000.
Our model: $150,000 plus a slightly higher initial project cost that includes maintenance for the first year, with a flat annual retainer for ongoing years.
The total cost is similar. But the relationship structure is entirely different. In our model, we're invested in the system performing well. In the traditional model, the firm has finished their obligation and moved on.
The better incentive structure has downstream effects that are hard to quantify but very real. Systems we maintain perform better over time. Systems maintained by disinterested third parties tend to degrade.
An Honest Caveat
This model works best for ongoing relationships. For one-off projects where a client is explicitly taking the code in-house or to another vendor, we adjust accordingly. We'll still write the cleanest, most maintainable code we can, provide thorough documentation, and ensure the handoff is smooth. But the maintenance-included model assumes a continued working relationship.
Most of our clients stay with us. We think the maintenance model is part of why.
What This Means for You
If you're evaluating software development vendors and none of them have mentioned maintenance, ask about it directly. Ask what happens when a bug surfaces six months after launch. Ask who patches dependencies when a CVE is published. Ask who handles the inevitable small improvements that emerge from real-world usage.
The answers will tell you a lot about how the firm thinks about the relationship they're proposing.