Software Support & Maintenance Retainers

Software isn't a purchase; it's a dependency. The day your custom system goes live is the day your business starts relying on something that needs watching, patching, and adjusting for as long as it matters — and the difference between that reality being cheap or expensive is entirely about whether it's planned.

This is the after-launch chapter of our software development practice, and — in keeping with the rest of this site — it comes with real numbers.

What Ongoing Support Actually Covers

"Maintenance" sounds like one activity; it's four:

1. Keeping it alive. Uptime and error monitoring with a human who gets alerted, log review, and incident response when something misbehaves at 2 a.m. Production software fails in ways that testing can't fully predict — the question is whether anyone notices before your customers do.

2. Keeping it safe. Every application stands on dependencies — frameworks, libraries, the platform underneath — and all of them ship security patches continuously. Applying them promptly, with testing so the patch doesn't break the app, is the unglamorous work that prevents the incident you'd otherwise read about in your own inbox.

3. Keeping it correct. Bugs surface for the life of any system — triggered by new data shapes, new usage patterns, or changes in the services it integrates with (payment processors and APIs change their side on their schedule). Retainer coverage means fixes with regression testing, not patches in panic.

4. Keeping it current. The business changes: a new service line, a changed rule, a report someone needs monthly. Retainers include an allotment of these small enhancements — which is what keeps a system fitting the business instead of drifting toward the legacy liability every unmaintained system becomes. It's the same decay curve we describe for websites, with higher stakes.

Why "Call Us If Something Breaks" Doesn't Work

The break-fix model feels thrifty and reliably costs more, for structural reasons:

• By the time you call, the cheap window has closed. The dependency that needed a routine ten-minute patch in March is the exploited vulnerability in August. Break-fix converts small scheduled work into large emergency work.
• Emergency work bills at emergency economics. Not just rates — an engineer arriving cold to a burning system spends the first hours rediscovering what a retained engineer already knows. You pay for the fire and the tour.
• Nobody is watching the gauges. Break-fix means your customers are your monitoring system. The failures that matter most — slow decay, silent data issues, a payment webhook that stopped firing — announce themselves late and expensively.
• The relationship inverts. Under a retainer, your system is a standing responsibility; under break-fix, you're a stranger in the queue behind every retained client — at precisely the moment you can least afford the wait.

We're deliberately retainer-first for the same reason we publish pricing: the model aligns our incentives with your system's health rather than its emergencies.

Our Retainer Model

$1,500–$5,000/month, scoped to system criticality — a back-office tool used weekly sits at the low end; a customer-facing product processing payments sits higher. (Industry rules of thumb put annual software maintenance at 15–20% of build cost; our ranges are consistent with that math on our published build prices.) Every retainer includes:

• Monitoring, alerting, and incident response with defined response expectations
• Security patching and dependency updates, tested before deploy
• Bug fixes with regression testing
• A monthly allotment of small enhancements
• A monthly plain-English report: what was done, what was found, what we recommend
• Priority access — retained systems jump the project queue by design

Work beyond the allotment — a significant new feature, a new integration — gets quoted as a mini-project at our standard $135–$175/hr with the same Statement-of-Work discipline as any build. And retainers run month to month after an initial term: software support you'd have to escape isn't support.

For systems we didn't build: we take these on after a paid audit — codebase, infrastructure, and security posture — so both sides know what we're adopting. Sometimes the audit's honest conclusion is that stabilization or modernization has to precede support; you'll get that with numbers, not surprises.

What a Retainer Month Actually Looks Like

The deliverable made concrete — a representative month on a mid-tier retainer: dependency updates reviewed and applied in a test environment, then production (typically several per month arrive; two or three matter). One monitoring alert investigated — a payment webhook that started returning intermittent errors after the processor's API change — fixed before any customer noticed. Two small enhancements from the allotment: a new field on the intake form flowing through to reports, and a tweak to an email template. One bug report from staff, reproduced, fixed, regression-tested. And the monthly report, one page, plain English: what changed, what was prevented, one recommendation (an aging integration worth modernizing next quarter, priced if you want it). Nothing dramatic — which is precisely the product. Drama is what the retainer is subtracting.

FAQ

How much does software maintenance cost?

$1,500–$5,000/month with us, scoped to criticality. The comparison to hold it against isn't zero — it's emergency rates times the incidents a retainer prevents.

What's the difference between this and a website care plan?

Scope and stakes. Website care plans (from $500/month) cover sites; software retainers cover applications — deeper monitoring, dependency chains, integrations, and regression testing. If your system has logins and business logic, it's this one.

Does the retainer include new features?

Small enhancements, yes — that's the monthly allotment. Substantial features get scoped as mini-projects at standard rates, which keeps the retainer price honest instead of padding it for work most months don't need. The line between "allotment" and "project" is drawn in the agreement, so it's never a negotiation at invoice time.

Can we handle maintenance in-house instead?

If you have engineering staff with capacity, genuinely yes — we'll hand over documentation, runbooks, and clean code that makes that possible; you own everything precisely so you have that option. The retainer exists for businesses that don't want to staff it.

What are your response times?

Defined per retainer tier and written into the agreement — criticality sets the number. What we don't do is publish a marketing SLA here that the contract doesn't back.

Our developer disappeared and left us with running software. Now what?

A distressingly common inquiry, and there's a standard playbook: secure the accounts first (hosting, domain, database — ownership recovery before anything else), then the audit, then stabilization in priority order. Most orphaned systems are recoverable; the expensive part is usually the months of drift before someone called. If the code and credentials exist anywhere, start there and start now.

---

Running custom software with nobody watching it? Tell us what it is and what it runs — we'll audit it and quote the retainer that fits, or tell you plainly what needs fixing first. Get in touch.