--- slug: "real-cost-of-maintaining-a-client-ai-workflow" title: "What It Actually Costs to Maintain a Client's AI Workflow" description: "A concrete cost breakdown of running a scoped MCP server for client fixes — build time, review overhead, hosting — compared to a CMS and ticketing stack." date: "2026-08-18" category: "Business" featured: false readingTime: 6 author: "Karlis Bērziņš" image: "/blog/images/real-cost-of-maintaining-a-client-ai-workflow.svg" --- ## "That Sounds Expensive to Maintain" Every time we describe [the small, scoped MCP server that lets a client fix bugs and copy by chatting with their AI assistant](/blog/small-mcp-server-skips-the-ticket-queue), the same question comes back: doesn't that cost more to keep running than just paying for a CMS seat? It's a fair question about AI agent development cost, and it deserves a real answer instead of a vibe. So here's the actual breakdown — what it costs to build, what it costs to keep running, and what it replaces. ## The one-time build cost The server itself is small on purpose: a handful of tools (read a file, propose a diff, open a branch, open a pull request), scoped to one repo, with no access to secrets or the production branch. For a project of that shape, initial build time runs **4 to 8 hours** — most of it spent deciding what the server *shouldn't* be able to do, not writing the tool definitions themselves. That's a one-time cost, billed once, not a recurring line item. Compare that to standing up a CMS properly: content models, roles and permissions, a staging workflow, training the client on an admin panel they'll use maybe twice a month. That's rarely a 4-hour job either — it's just a cost people are used to paying, so it doesn't get scrutinized the same way. ## The recurring cost: review time, not infrastructure This is the part people assume is the expensive bit, and it isn't. The server has no meaningful hosting cost — it's a thin process, not a service handling traffic. The actual recurring cost is human review time, and it's smaller than most tickets ever were: - **Reviewing a pull request from a well-scoped agent**: 2 to 5 minutes. The diff is small because the tool surface is small — it can't accidentally touch fifteen files, because it only has tools for touching the ones that matter. - **Merging**: seconds, once it looks right. - **The occasional rejected or reworked diff**: maybe one in ten needs a follow-up message ("also update the mobile breakpoint"), which costs another round trip, still measured in minutes. Across a typical month of small fixes — copy tweaks, layout nudges, minor bugs — that's **well under an hour of our time**, spread across however many changes came in. Not zero. Genuinely small. ## What it replaces The honest comparison isn't "MCP server cost vs. zero." It's what the old path cost in time nobody was billing for: - a ticket written, often with a screenshot and a description of *where* the problem was, not just what it was - a triage pass to route it - a wait for someone to pick it up - a CMS login, if the fix even lived there, plus the time to relearn which field maps to which visible thing - a back-and-forth to clarify what "the button" meant, because the client isn't fluent in the content model's vocabulary None of that shows up on an invoice. It shows up as the gap between "I noticed this typo" and "it's fixed," which is often measured in days for something that takes minutes once someone actually sits down with it. The MCP server doesn't eliminate the minutes of actual work. It eliminates almost everything around them. ## Where the cost is real, and worth naming honestly We're not going to pretend this is free: - **Scoping it correctly takes real judgment**, not just engineering time. Getting the tool surface too narrow makes it useless; too wide makes it a liability. That judgment call is worth paying for, and it's most of the build cost above. - **Review time doesn't disappear, it moves.** Someone still has to read every diff. For a project with dozens of small changes a week, that adds up to real hours, just far fewer than the ticket path ever took. - **It doesn't scale to big changes.** A new feature, a redesign, a data migration — none of that belongs in this workflow, and trying to force it through the same narrow tool surface would be the wrong kind of cheap. ## The actual math For a small site with a steady trickle of minor fixes — the profile this is built for — the rough shape looks like: - **One-time**: half a day to a day of build time, paid once. - **Recurring**: under an hour a month of review time for most clients, scaling roughly linearly with how many small changes come in. - **What it replaces**: a CMS subscription that gets used for exactly this and nothing else, plus the actual time cost of tickets that used to sit for days before anyone touched them. The number that actually matters isn't the build cost — it's how much smaller the recurring cost is than what a proper ticket-and-CMS setup ends up costing once you count the labor, not just the software line item. ## What's next We're currently wiring this server together with a couple of others already in use — one that surfaces design tokens, one with visibility into page analytics — so the review overhead stays flat even as the assistant can pull more context on its own before proposing a change. The cost model doesn't really change with that; it's still one small diff to read per fix. What changes is how much of the thinking happens before the pull request lands in front of us, instead of after. If you're weighing whether this is worth building for a project of your own, the question to ask isn't "what does the server cost" — it's "what does an hour of review time a month cost, compared to what you're paying for a CMS seat and the hours nobody bills for around it." See the [full cost-of-ownership comparison](/ai-agent-development-cost-comparison) for how a one-time build stacks up against a subscription or an in-house hire over a year, not just the build itself.