Chapter 15: The Support Model
We operate two primary support models, and determining which one fits is a conversation that should happen during or immediately following project delivery — when sentiment is high, context is fresh, and the client is thinking about what comes next.
Support Models at a Glance
| 25% Maintenance Model | FTE Placement Model | No Support Needed | |
|---|---|---|---|
| What it is | Annual insurance contract | Dedicated full-time developer | Clean handoff |
| Cost | ~25% of original project cost/year | Monthly staffing fee | $0 |
| Who manages | Benmore | Client | Client |
| Best for | Stable, feature-complete systems | Mission-critical, evolving systems | Strong internal team |
| Covers | Bug fixes, patches, dependency updates, monitoring | Active development, operations, ongoing optimization | N/A |
| Does NOT cover | New features, scope expansion | Strategic product direction | N/A |
| Boundary | Spec Tree (in spec = maintenance; new = change order) | Time and capacity | N/A |
| AI leverage | AI knowledge agent + support dev = fast resolution | Single dev manages more than pre-AI | N/A |
Maintenance and Insurance: The 25% Model
Our standard support model is structured as an annual maintenance contract priced at 25% of the original project implementation cost — aligned with the widely cited industry benchmark of 15–25% of original development cost for annual software maintenance [33]. Think of this as insurance for your software. You’re not paying for a developer to sit around waiting for something to break. You’re paying for guaranteed access to a team that has deep context on your system, defined response times, and the capability to resolve issues quickly when they arise.
What this covers is straightforward. Bug fixes and defect resolution — if something isn’t working as defined in the Spec Tree, we fix it. Dependency and security updates — keeping libraries, frameworks, and infrastructure current and patched against known vulnerabilities. Minor adjustments — small changes that don’t constitute new features but are necessary for the system to continue operating as intended in a changing environment. An API provider changes their response format. A browser update breaks a CSS behavior. A regulatory update requires a field to be added to a form. These are the kinds of things that fall within the maintenance umbrella. Monitoring and incident response — depending on the project, we set up monitoring dashboards and alerting so issues are caught before clients notice them. When something goes wrong, we respond within defined SLAs.
What this does not cover is new feature development, significant scope expansion, or fundamental architectural changes. Those are separate engagements — and that’s an important boundary to maintain. If the maintenance contract becomes a backdoor for unlimited feature requests, you end up in the same scope creep death spiral we spent three chapters talking about. The Spec Tree, once again, serves as the boundary. If the request falls within the original spec, it’s maintenance. If it’s net new, it’s a new engagement or change order with its own scoping, timeline, and cost.
25% Maintenance Model: Coverage Reference
Included:
Not Included:
Rule of thumb: If it’s in the Spec Tree, it’s maintenance. If it’s net new, it’s a new engagement.
The 25% model works particularly well for a specific profile of client: the project is stable, the client has internal technical capacity or is building it, and their primary concern is knowing that someone who understands the system can step in when needed. It’s peace of mind. Many of our clients on this model go months without needing us, and when they do, the issue gets resolved in hours because we already have context. That’s the value proposition — not volume of work, but speed and quality of response when it matters.
From our side, the economics work because of how AI has compressed the resolution cycle. Issues that would have taken a full day of investigation and patching in the pre-AI era can now be diagnosed and resolved in a fraction of the time. The AI knowledge agent we set up during handoff — the Claude Code instance with full project context — becomes an accelerant here. A support developer can spin up the agent, describe the issue, get oriented in the codebase instantly, and implement a fix with agentic tools. The Spec Tree provides the acceptance criteria. The Operational Runbook provides the deployment procedure. What used to require the original developer’s tribal knowledge now requires access to the right assets and a competent developer with AI tools. This is how we scale support across a growing portfolio of clients without burning out our team.
One thing worth being transparent about: the 25% figure is not arbitrary, but it is a benchmark. For larger projects, the percentage may adjust downward. For smaller projects, it might adjust upward to ensure the economics make sense for both sides. The conversation around pricing should always be rooted in what the client actually needs and what the realistic support burden looks like. A simple CRUD application with no third-party integrations has a fundamentally different support profile than a system with five external API dependencies, real-time data processing, and HIPAA compliance requirements. Price accordingly and explain why.
Full-Time Support: The FTE Transition
For some projects, the 25% maintenance model isn’t enough. The system is mission-critical. It’s evolving constantly. There are daily operational needs — not just break-fix, but active development, user support, data management, and ongoing optimization. In these cases, the right move is transitioning to a full-time embedded team member through our staff placement model.
This is a natural graduation from the FDE engagement. The FDE has delivered the project, the knowledge transfer is complete, and the client needs ongoing, dedicated support that exceeds what a maintenance contract can provide. Rather than keeping the FDE on the project indefinitely — which conflicts with the shock trooper mandate — we place a full-time developer who has been trained on the system using our handoff process. They’ve gone through the development-based training, worked through the curated project scenarios, and have access to the AI knowledge agent. They’re not starting cold.
The key distinction here, and this echoes what we discussed in the discovery chapters, is ownership transfer. Under the FTE model, the client manages the placed team member. They set priorities. They determine what gets built next. The placed developer is, functionally, an extension of the client’s team — not a Benmore-directed resource. We provide the talent, we ensure they’re onboarded and capable, and we remain available for escalation or strategic consultation. But day-to-day direction comes from the client.
This distinction matters for a couple reasons. First, it aligns expectations. Clients getting full-time support need to understand that they are now in the driver’s seat. If they want strategic input on what to build next, that’s a separate FDE engagement. The FTE is there to execute and maintain, not to own product strategy. Second, it protects the integrity of the work. If we maintained strategic ownership while also providing full-time support, we’d be incentivized to keep building — to keep finding things that need to be done to justify the placement. That’s the cancer we talked about in the preface. By cleanly separating strategy from execution in the support phase, we remove that incentive and keep the relationship honest.
The FTE model also serves as a bridge for clients who are building out their own internal engineering teams. Rather than hiring cold into a system they don’t fully understand, they can operate with a Benmore-placed developer while they recruit, and then transition the placed developer off once the internal team is ramped. We’ve seen this work extremely well with startups that are post-launch and starting to build their first engineering hires. The placed developer provides stability while the client builds capacity, and the handoff assets we’ve already created — Operational Runbook, System Overview, Spec Tree, AI knowledge agent — make onboarding new internal hires significantly smoother.
Pricing for the FTE model is structured as a monthly staffing fee, aligned with market rates for the seniority level required. This is more straightforward than project-based pricing because the scope isn’t bounded by a spec — it’s bounded by time and capacity. The client gets a full-time resource. They use that resource as they see fit within the technical domain of the project. Simple.