--- title: What a Software Maintenance Retainer Looks Like url: https://varstatt.com/jurij/p/what-a-software-maintenance-retainer-looks-like author: Jurij Tokarski date: 2026-04-26 description: Software maintenance services on a weekly retainer: dependencies, security, performance, monitoring, bug fixes, and new features — same diligence as building. section: Blog (https://varstatt.com/jurij/archive) tags: retainer-shapes (https://varstatt.com/jurij/c/retainer-shapes) --- Most of the industry treats software maintenance as a separate phase from building. Different team, different rate, different mindset. The handbook here disagrees: [development and maintenance aren't separate](/principles/diligence/no-split). They're the same work, applied to a product at different points in its life. So a maintenance retainer at Varstatt is the same retainer as a build retainer. Same person, same $997/week, same task board, same cadence. What changes is the starting point: the product is already running. The work blends keeping it healthy with shipping new things on top of it — both in the same engagement, against the priorities you set week by week. ## Maintenance Is Diligence Applied to a Live Product When I build something new, I'm running a set of [diligence](/principles) practices in parallel with shipping. [Monitor from day one](/principles/diligence/monitor-day-one) so problems surface before users notice. [Observe and improve](/principles/diligence/observe-improve) so the next version is informed by real usage. [Documentation emerges](/principles/diligence/documentation) from the work, not as a separate task. [Incident response](/principles/diligence/incident-response) when something breaks — stop the bleeding first, then root-cause. A maintenance retainer is those same practices, pointed at a product that's already running. The build phase is over; the diligence phase continues. Dependencies still need updating. Security still drifts. Performance still degrades as data grows. Third-party APIs still ship breaking changes. Bugs still surface at edges that didn't exist at launch scale. Someone with the right judgement still needs to be looking. The work isn't smaller than building — it's the same kind of work, just less of it per week, and the cadence is set by what the live product is asking for instead of what's on a roadmap. ## Onboarding Onto Software I Didn't Build Most maintenance retainer requests start the same way: "we have something running, the original developer is gone or moved on, can you take it over?" Yes. Onboarding onto an inherited codebase is part of the work. Week one is reading the code, mapping the data model, identifying what's load-bearing, finding the parts the original team understood and the new team will trip over. Production credentials, deploy pipeline access, monitoring dashboards, third-party accounts — handed over deliberately, with [client owns everything](/principles/philosophy/client-owns-everything) as the baseline. By the end of the first couple weeks, the codebase is in my head deeply enough to make changes safely. Dependencies are current. Monitoring is honest. The first round of "this looks fragile" issues is either fixed or queued. From there, the steady-state retainer rhythm starts. If the codebase needs more than care — if it's structurally past its useful life — that surfaces in onboarding, and the [legacy modernization](/jurij/p/what-a-legacy-app-modernization-looks-like) shape is the right next step instead. The maintenance retainer doesn't pretend a rewrite isn't needed when one is. ## What the Work Actually Looks Like A typical week, in no particular priority order: **Dependencies.** Node, framework, library, transitive package updates. [Done weekly, this is 30 minutes and a deploy. Done annually, it's a two-week migration project](/jurij/p/why-weekly-retainers-work-better-than-sprints). **Security.** CVE feeds, Dependabot alerts, npm audit. Triaged, applied, redeployed. Vulnerabilities don't accumulate. **Runtime upgrades.** Node minor versions, Postgres point releases, Firebase SDK majors. Steady cadence keeps the platform on supported versions. **Performance.** [Monitoring](/principles/diligence/monitor-day-one) catches drift early — a query that was instant at 1k rows starts slowing at 50k, a bundle creeping past a budget, a Cloud Function cold-start showing up in real analytics. Caught early, these are short fixes. Caught late, they're a sprint. **Bug fixes.** The actual ones. Edge cases that surface only at scale. [Fixed and shipped the same week](/principles/diligence/incident-response), not added to a backlog. **Monitoring tuning.** Sentry signal-to-noise drift, dashboards going stale, alerts that no longer correlate with real problems. Pruned so the alerts you do get mean something. **Third-party API drift.** Stripe, Resend, OAuth providers, webhook signatures — the change-log work that prevents finding out you're broken by losing a week of payments. **New features.** This is the part most maintenance offerings can't do. The retainer is the same retainer that builds — same person, same cadence, same architecture judgement. When the founder needs a CSV export on the admin page, an integration with a new payment provider, a redesign of the onboarding flow, or a whole new module — that ships in the same retainer. The maintenance work and the new build work share a task board; you set the priorities. There's no separate engagement, no re-scoping, no upsell, and no handoff to a different team that doesn't know the codebase. ## Why Same Person and Same Retainer Matters The classic split — build team ships v1, hands off to a maintenance team — destroys the context that makes maintenance fast. The build team never sees how their decisions hold up in production. The maintenance team works forensically, afraid to touch things they don't understand. Velocity drops on both sides. [Single-person continuity](/principles/philosophy/solo-model) inverts that. The same engineer who shipped the auth flow knows why session tokens expire after 12 hours instead of 24. The person who chose Firestore over Postgres knows which queries were intentionally denormalized and which were accidental. When someone needs to inherit the codebase from elsewhere, the onboarding pays for itself by week three — and after that, the same continuity holds. [The retainer model](/) holds this together. Weekly billing, weekly cadence, async-first communication, [pause anytime](/principles/diligence/pause-not-end) through Stripe when there's genuinely nothing on the board. The same engagement that builds new features carries the maintenance work without a contract change, a different rate card, or a different person picking up the phone. ## Who This Fits Founders post-launch, with real users, where the product is critical but doesn't need a full-time engineer. Operators who acquired a small SaaS and need someone competent keeping it healthy. Solo founders running products built years ago that still print money and need senior eyes once a week. Teams whose original contractor moved on and now need someone to inherit the work and keep it running. Founder-built apps — vibe-coded, no-code-graduated, weekend-project-grown — that crossed the line where breakage costs real money. The pattern across all of these: a working product, real users or real revenue, and a founder who doesn't want to think about whether the dependencies are up to date. ## Other Shapes the Retainer Takes Same retainer, different shapes — pick the one that matches the work in front of you: - **[What a Code Audit Looks Like](/jurij/p/what-a-code-audit-looks-like)** — start here when you're inheriting a codebase you don't yet understand - **[What a Legacy App Modernization Looks Like](/jurij/p/what-a-legacy-app-modernization-looks-like)** — when the maintenance burden is symptomatic of a deeper problem - **[What a Fractional CTO Engagement Looks Like](/jurij/p/what-a-fractional-cto-engagement-looks-like)** — when "keep it alive" expands into "build the next chapter" - **[All retainer shapes →](/jurij/c/retainer-shapes)** ## How to Start The path is the same for every shape: 1. **[Submit a project brief](/brief)** — 2–3 minutes. Within 24 hours, you get an honest read on whether this engagement fits. 2. **15-minute discovery call** — confirm scope and timing, no sales pitch. 3. **Subscribe to the weekly retainer** — work begins the next business day. Cancel anytime through Stripe, no paperwork. If you have questions before any of that, the [project brief form](/brief) has a free-text field — write whatever you need to.