Who owns the systems a consultant builds?

Here's an inconvenient truth about consulting: most engagements look successful at the end and fail twelve months later.

The slide deck got delivered. The system got built. The owner felt good about the engagement. Six months later, the consultant is gone, the system is half-running, and the team is back to the spreadsheet they had before. The whole thing quietly unwound.

I've watched this happen from both sides, first as an operator paying for it, now as the person doing the building and working hard to never be the one who caused it. The problem isn't bad consulting. The problem is that almost no engagement is structured to transfer cleanly. Ownership is treated as a final-week activity. By then it's already too late.

This post is what I do differently. It's the fourth step in my Approach, and arguably the most important one. Transfer is the deliverable. Everything else just makes the transfer possible.

What "transferred" actually means

I call a system transferred when, twelve months after I've stepped back, four things are still true:

1. It still runs. Not "it ran for a while and then drifted." It's still doing the work it was built to do.
2. Someone on your team owns it. Not the consultant. Not "the IT person." A named human whose role description mentions it.
3. Your team can extend it. Small changes, a new field, a new vendor, a new edge case, happen without an external call.
4. You'd choose to renew the tooling. The cost is justified by the value, twelve months later, in retrospect.

If all four are true, transfer worked. If any one is false, the engagement ultimately failed, even if it looked great at the launch date.

That definition is uncomfortable. It moves "success" from the demo day to a year later. It also changes how I structure every part of the engagement before that day.

The two things that work differently

Two parts of what I sell are deliberately not handed over on day one, and I'd rather say so here than in the fine print:

• Hosting. I host the sites I build, on a Care Plan. Your domain stays in your name the whole time, and the hosting transfers to you on request. Most owners would rather someone else keeps the site up, backed up and patched; the ones who want it in-house get it.
• The Lead System. It is installed on your accounts and run for a monthly fee, not sold. Stop paying and it switches off. Your leads, contacts and conversations live in your own tools and stay yours either way.

Everything else I build to order, the code, the automations, the agents, the documentation, is yours to keep, run and walk away with.

The four-part Transfer Playbook

I don't transfer systems in the last week of an engagement. I start on day one. Here's what that actually looks like.

1. Documentation isn't a write-up, it's a deliverable

Most consulting documentation is written at the end, by the consultant, in the consultant's voice, for an imaginary audience. Nobody reads it.

I write documentation differently:

• In your team's voice. I interview the person who'll own each component and write the doc as if they wrote it themselves. They edit before publishing.
• As I build, not after. Every meaningful component ships with its runbook the same week. End-of-project doc sprints are a code smell.
• In your existing system. Notion, Confluence, Google Docs, SharePoint, wherever your team already lives. I don't introduce a new doc tool just to leave it behind.
• In layers. Quick reference (the "card", under one page) for daily use. Runbook (the "playbook", 3–5 pages) for routine maintenance. Architecture doc (the "map") for the rare deep fix.

A well-documented system isn't one with the most words. It's one where someone two years from now, who never met me, can fix it without panic.

2. The champion plays the build, not just receives it

Every engagement has one person on your side named as the champion before I start. (See the readiness diagnostic, gate #4.) The champion isn't a stakeholder who shows up to weekly check-ins. They are in the build with me.

What that looks like:

• They sit in on every architectural decision, even the small ones. Not to approve, to absorb.
• They write portions of the system themselves once we're past the framing stage. With my help, but with their hands on the keyboard.
• They run the first few production cycles with me watching, then with me on standby, then alone.
• They own the runbook. I draft, they edit, they ship.

The champion can be technical or non-technical. The pattern works the same. What matters is that by the end of the engagement, they've built parts of the system themselves and know it from the inside.

3. I deliberately under-build the parts that should change

There's a temptation in consulting to over-engineer for "future-proofing." Every edge case. Every conceivable variation. Every theoretical scaling concern.

It's almost always wrong. Over-engineered systems are more expensive to build, harder to understand, and, fatally, harder for an internal team to extend safely. Six months later they're afraid to touch the thing because it's "the consultant's code."

My principle: the system should look like something your team could have built, with a little outside help. Not something they could never reach. So I:

• Use the boring, well-documented tools your team can hire for. Not the cutting-edge stack only the consultant knows.
• Pick obvious, plain code over clever code, every time.
• Leave the complexity at the edges where it's needed, the integration that's genuinely hard, the AI prompt that's been tuned through 200 examples, and keep the middle simple.
• Ship the smallest version that works, not the version that handles every imaginable case.

This is sometimes painful for me as a builder. It is always right for the client.

4. The handoff is a phased reduction, not a single event

The last week of an engagement isn't "training week." Training as a single week is a fantasy. Real handoffs are phased reductions in my involvement, starting from week one:

Week	My role	Champion's role
1–2	Driver	Co-pilot, observing, asking questions, taking notes
3–4	Co-pilot	Driver, running components with my active support
5–6	Standby	Driver, running everything; I step in only on hard problems
7+	On call	Owner, the system is theirs; I answer questions for 30 days

By the time the engagement formally ends, the champion has been running the system for two-plus weeks already. The "handoff" is a paperwork formality. The functional handoff happened in week three.

The 30-day grace period

Every build includes 30 days of support after launch. No clock. The champion can email or message any question, and I answer within one business day.

This isn't a sales hook. It's the cheap-insurance phase. Anything I missed in the build, anything that broke from a vendor change, anything the team hits in the first month of real use, I cover. After 30 days, keeping it monitored and tuned is a Care Plan, month to month with thirty days notice, and for anything I built to order it's optional.

What this changes about how I sell

The transfer-first model changes the economics in ways that are good for the client and a little uncomfortable for me:

• Builds end on time. I don't drift into "ongoing advisory" by accident. What I built to order is yours.
• I can't sell you what I already gave you. The runbook lives in your Notion. The system runs without me. There's no pull to come back unless you have a new problem worth scoping.
• Repeat work should be on new problems, not old ones. The second build should be a second capability, not a rescue of the first.
• I stay small, deliberately. A business that depends on long, drifting engagements grows differently than one that depends on clean, transferred ones. I'm optimizing for the second.

That's the trade-off. I believe it's the right one, for the client, and for the kind of business I want to run.

What it looks like for you

Here's what to ask anyone you're considering, including me, to know whether they're actually structured for transfer:

1. "Who on my team will own this six months after you leave?"
2. "What documentation will exist, in what tool, by what date?"
3. "What does week-by-week handoff look like, starting in week one?"
4. "What happens at month thirteen if it breaks?"
5. "Are you willing to write into the contract what 'successfully transferred' means?"

If those questions get vague answers, walk. Ownership has to be designed in from day one, and that requires someone willing to put it in writing.

The bottom line

What makes my approach different isn't the framework. Lots of consultancies have a four-step framework. It's that the fourth step, transfer, is treated as the core deliverable, not the closing ceremony. Everything else is in service of it.

The point of this work, done well, is to make myself unnecessary for the things I built to order. The systems should outlast the engagement. The team should know more after I step back than they did before I arrived. And six months later, the honest sign of success is that you haven't needed to call me about it, because everything's still running.

That's the work. That's the whole point.

If that resonates, a 30-minute call is the fastest way to know if it's the right fit for what you're trying to move.