Part 5: Supporting the Ship

Chapter 16: When to Recommend What

By Richard Buehling

Support Model Decision Tree

 ┌──────────────────────────────────────────────┐
 │                                              │
 │  Project delivered.                          │
 │  What does the client need going forward?    │
 │                                              │
 └──────────────────────┬───────────────────────┘
                        │
                        ▼
 ┌──────────────────────────────────────────────┐
 │                                              │
 │  Does the client have internal technical     │
 │  resources AND the system is stable?         │
 │                                              │
 └──────────┬──────────────────────┬────────────┘
            │                      │
          YES                      NO
            │                      │
            ▼                      ▼
 ┌──────────────────────┐    ┌──────────────────────────────────┐
 │                      │    │                                  │
 │  Do they need any    │    │  Does the system need daily      │
 │  support?            │    │  active development or ops?      │
 │                      │    │                                  │
 └───────┬──────┬───────┘    └──────────┬──────────┬────────────┘
         │      │                       │          │
       YES      NO                    YES          NO
         │      │                       │          │
         ▼      ▼                       ▼          ▼
 ┌──────────┐ ┌──────────┐    ┌────────────┐ ┌────────────┐
 │          │ │          │    │            │ │            │
 │   25%    │ │  Shake   │    │    FTE     │ │    25%     │
 │  Model   │ │  hands   │    │ Placement  │ │ Mainten.   │
 │          │ │  & go    │    │   Model    │ │   Model    │
 │          │ │          │    │            │ │            │
 └──────────┘ └──────────┘    └────────────┘ └────────────┘

Key Signals:

Signal Recommendation
System stable, client has some tech capacity 25% Maintenance
Primarily reactive needs (bugs, patches, security) 25% Maintenance
Predictable annual cost preferred 25% Maintenance
Daily active development needed FTE Placement
No internal tech resources FTE Placement
Mission-critical with downtime risk FTE Placement
Roadmap extends well beyond original spec FTE Placement
Strong internal team, good handoff No support needed

Determining which support model to recommend is part of the FDE’s responsibility during the delivery phase. Like everything else in our process, this should be rooted in the client’s actual needs, not in what generates the most revenue for us. Here are the signals we look for.

The 25% maintenance model is the right fit when the project is stable and feature-complete relative to the agreed spec. When the client has internal technical resources — even limited ones — who can handle day-to-day operations with the help of our documentation and AI knowledge agent. When the system’s support burden is primarily reactive — things breaking, dependencies changing, security patches — rather than proactive development. And when the client’s budget is better served by a predictable annual cost rather than a full-time headcount commitment.

The FTE model is the right fit when the system requires daily or near-daily active development or operational management. When the client does not have internal technical resources and isn’t planning to hire in the near term. When the project is mission-critical and downtime or slow response times carry significant business risk. And when the client’s roadmap for the system extends well beyond the original spec, and they need hands to keep building.

There’s also a third scenario that comes up more than you’d expect: the client doesn’t need either. They’ve got a solid internal team. The handoff went well. The documentation is comprehensive. They’re good. In those cases, the right recommendation is to shake hands, let them know we’re here if they need us, and move on. Pushing a support contract on a client who doesn’t need one is antithetical to everything we’ve talked about in this book. It erodes trust, it feels slimy, and it’s short-sighted. That client will remember that we didn’t try to squeeze them, and they’ll come back when they actually need something — or they’ll refer someone who does.