Why We Don't Offer Monthly Maintenance Plans

Most web agencies love maintenance plans. Recurring revenue, predictable cash flow, a client who pays $150 to $500 a month for years after the project ships. From the agency's perspective, it's a great business model. From the client's perspective, it should raise a question nobody seems to ask: why does my website need a monthly babysitter?

We don't sell maintenance plans. Never have. And after 25 years of building websites, we don't plan to start.

The Maintenance Industry Exists Because Most Sites Are Built Poorly

The typical WordPress maintenance plan covers plugin updates, security monitoring, backups, uptime checks, and maybe a few hours of "minor edits." Agencies charge $100 to $500 a month for this. Some charge more. A mid-range plan at $300/month costs $3,600 a year. Over five years, that's $18,000 on top of whatever the original build cost.

What's actually happening during those billable hours?

Plugin updates, mostly. The average WordPress site runs 20+ plugins, and each one needs updating independently. Some updates conflict with other plugins. Some break the theme. Some introduce new security holes that require yet another patch. The agency runs the updates, tests for breakage, and fixes what went wrong. Month after month.

But here's the part nobody says out loud: a well-built WordPress site with eight to twelve carefully chosen plugins, a custom theme, and proper auto-update configuration doesn't need someone manually running updates every month. WordPress has shipped automatic minor security updates since version 3.7. Plugins and themes can be configured for automatic updates since WordPress 5.5. A quality hosting provider handles backups and uptime monitoring as part of the hosting plan you're already paying for.

The maintenance plan isn't solving a problem. It's managing one that was baked into the build from day one.

What Creates Maintenance Dependency

We've audited hundreds of sites over the years. The ones stuck on maintenance plans share the same patterns.

Plugin bloat. The site runs 30+ plugins because the developer used a page builder that demands add-on packs, caching plugins, image optimization plugins, and security plugins to compensate for what the builder itself generates. Every plugin is a dependency. Every dependency is a future update conflict. We wrote about this problem in depth in our piece on the hidden costs of page builders.

No documentation. The client can't update their own content because nobody trained them. They can't troubleshoot a broken contact form because there's no record of how it was built. So they call the agency. Every month. Dependency by design, whether anyone intended it or not.

Fragile architecture. The theme was built with hardcoded workarounds instead of clean, standards-compliant code. CSS overrides stacked on top of other overrides. JavaScript that breaks when WordPress core updates. The site is a house of cards, and the maintenance plan is the fee for not letting it fall.

Proprietary lock-in. The agency built the site on their own proprietary tooling or a heavily customized codebase that only their team understands. Switch developers? Start over. The partnership becomes a trap. We talked about what to look for when hiring a developer specifically to help people avoid this.

Patchstack's 2025 State of WordPress Security report found 7,966 new vulnerabilities across WordPress plugins and themes during 2024 alone. That's 22 per day. But 96% of those vulnerabilities were in third-party plugins, not WordPress core. WordPress itself had only seven security issues that year, none of them serious. The vulnerabilities live in the plugins. And the sites that need the most maintenance are the ones running the most plugins.

Fewer plugins. Fewer problems. Less maintenance. The math isn't complicated.

What "Done Right the First Time" Looks Like

When we finish a project, our goal is simple: you shouldn't need us anymore. Not because we don't want a relationship with our clients, but because a well-built product shouldn't require its builder on retainer to keep functioning.

Here's what that means in practice.

We choose the right platform for the job. Sometimes that's WordPress. Sometimes it's Astro, or a headless CMS, or a static site that doesn't need a CMS at all. We've written about what proper investment in a website looks like, and a big part of that investment goes toward picking the right architecture from the start. A blog that publishes twice a month doesn't need the same setup as an e-commerce site processing 500 orders a day.

We keep the plugin count low. A custom WordPress build from us typically runs eight to twelve plugins. Each one is vetted for active maintenance, security history, and whether it's actually necessary. If we can build the functionality ourselves in clean PHP, we often do. No page builders. No add-on packs. No cascading dependency chains.

We configure automatic updates. WordPress core security patches apply themselves. Plugin and theme auto-updates get enabled where safe. For sites on managed hosting like WP Engine or Flywheel, the host handles staging environments for major updates automatically. We set this up before handoff so the client doesn't have to think about it.

We write documentation. Real documentation. Not a one-page PDF that says "click here to log in." We document the site architecture, how the theme works, how content types are structured, where third-party integrations connect, and how to do every common task the client will need to do. If a different developer needs to pick up the project in two years, they can.

We train the client. Before handoff, we walk through content editing, media management, and basic troubleshooting. Most of our clients manage their own content within a week. They don't need to call us to change a phone number.

We hand over everything. Domain credentials, hosting login, CMS admin, analytics, email accounts, source code. All of it. The client owns the entire stack. If they want to hire someone else next year, they can do that without rebuilding from scratch.

If your developer built your site well, you shouldn't need to pay them monthly to keep it running. If they didn't, the maintenance plan is the ongoing cost of that decision.

When You Actually Need Ongoing Support

We're not pretending every website runs itself forever. Websites aren't appliances. They exist in an environment that changes, and sometimes those changes require professional attention.

WordPress major version updates happen two to three times a year. Most are smooth. Occasionally, one will break a plugin or introduce a compatibility issue with a custom theme. That's a support call, not a maintenance plan. We offer per-incident support for exactly this situation. You call us when something breaks. We fix it. You pay for the actual work, not a monthly retainer that subsidizes months when nothing happened.

Security incidents do occur. If your site gets hit despite proper configuration, that's a remediation project. Those are real, scoped work with a defined outcome, not ongoing fees for checking whether something went wrong.

Content strategy changes. You're adding a new product line, restructuring your navigation, or integrating a new booking system. That's development work. Scope it, quote it, build it, hand it off. Done.

What none of these situations require is a recurring monthly payment for someone to log into your WordPress dashboard and click "Update All."

The Business Model Nobody Questions

The web development industry has normalized maintenance plans to the point where clients assume they're necessary. They're not. They're profitable for agencies. There's a difference.

A $300/month maintenance plan generates $3,600/year in near-passive revenue per client. An agency with 40 clients on maintenance plans earns $144,000 annually for work that, on most months, amounts to clicking a few buttons and running automated scans. Some agencies are honest about what the plan covers. Many aren't.

We've talked to business owners who've paid $200/month for years and, when asked what the plan includes, couldn't tell us. They knew they were getting "updates and security." When we audited the sites, the plugins were outdated, security headers were missing, backups weren't configured, and the SSL certificate had lapsed. The maintenance plan was a subscription to the illusion of maintenance.

We'd rather build something right and walk away. Our services are structured around projects with defined scope and clear endpoints. You pay for the work. You own the result. You don't pay us rent on something that's already yours.

We're not being generous here. Self-sufficiency is a business philosophy. We'd rather build six excellent projects a year than maintain 40 mediocre ones. The clients we want are the ones who value self-sufficiency, who want to understand their own technology, and who see their website as a business asset they own outright.

What This Means for You

If you're currently paying for a maintenance plan, that's not automatically a problem. Some plans are legitimate, particularly for large sites with complex integrations, frequent content changes, or strict compliance requirements. A hospital network with 200 pages and a patient portal probably does need dedicated support.

But a ten-page business website for a Calgary law firm or a restaurant with an online menu? No.

Ask your current provider three questions. What did you actually do on my site last month? Can you show me the logs? And what would it cost to make this site self-sufficient so I don't need this plan anymore?

If they can answer all three clearly, you might have a good provider. If the answers are vague, you're paying for a safety net that may have holes in it.

We build websites that don't need us after launch. That's the product. And the cheapest maintenance plan is the one you never have to buy.

Sources

• Patchstack — State of WordPress Security in 2025 — Annual report documenting 7,966 new WordPress plugin and theme vulnerabilities in 2024, with 96% found in plugins, and only seven in WordPress core
• WordPress.org — Plugins and Themes Auto-updates — Official documentation on configuring automatic updates for plugins and themes since WordPress 5.5
• WordPress Developer Resources — Upgrading WordPress — Official documentation on WordPress core automatic security updates, enabled by default since version 3.7
• Patchstack — 2025 Mid-Year Vulnerability Breakdown — Mid-year analysis showing continued growth in plugin vulnerability disclosures and patching gaps
• web.dev — Interaction to Next Paint (INP) — Google's Core Web Vital metric for responsiveness, relevant to sites burdened by plugin bloat and excessive DOM size
• Simple Thread — Checklist for Handing Off a Software Project — Best practices for project handoff documentation, including architecture docs, deployment guides, and knowledge transfer
• Make WordPress Plugins — Plugin Check Security Reports — WordPress.org's 2025 initiative for automatic security reporting on plugin updates