Built to Leave:
Designing the Engagement to End Well

When I scope a project with a new client, the first question I ask isn't "what should we build?" or "what should we fix?" It's "what happens when I'm not here anymore?"

That sounds backwards. Most consulting starts with the work and ends with the timeline. The departure plan, if it exists, is a deck slide near the end. The default assumption is that the consultant stays. On retainer, on call, available for the inevitable "can you fix this real quick" texts.

I don't run engagements that way. The reason is simple. A process the client can't run without me isn't theirs. A system the client can't update without me is a leash. The work I do for clients is supposed to be theirs when I leave.

The work isn't always the same thing

A given engagement might be writing a piece of custom software. It might be helping a client get more out of software they already pay for. It might be cleaning up a monthly close that takes too long for the wrong reasons. It might be sitting with an owner and mapping out how the team's time is spent, and whether the work is matched to the people doing it. It might be repositioning the file system, fixing the marketing TV that's been frozen in the lobby for a month, or talking through which roles to hire next.

The throughline isn't the deliverable. It's the operational improvement, whatever shape it takes.

What "designing for departure" looks like depends on the shape of the work. The principle is the same: when I'm gone, the team should be able to keep running what we put in place.

For a process change, that means a written procedure and a sit-down with the people who'll keep doing it. A one-pager for the new hire next year.

For something physical, like a new file layout or fixing the lobby TV, it might just mean walking the team through what changed and writing a short note about why things are where they are now.

For software, the bar is higher.

What it looks like on a software engagement

My consulting practice's productized platform, Tallera™, is in daily production at a Boise-area construction contractor. It runs 25 modules across the accounting team's workflow, with 159 versioned releases shipped to date. The accounting team uses it every day.

The design decisions that mattered for the long run weren't about features. They were about what happens after I leave:

• Updates happen without me. An automated system builds each release. The client clicks "Check for updates" inside the app and the new version installs itself. My machine doesn't have to be online. My availability doesn't have to be coordinated.
• The keys that verify each update don't live on my laptop. They live in a system the client can audit. If I lose my hardware, the client's update path is unaffected.
• The client gets a working installed application, an update mechanism, a 28-chapter user manual, and a departure checklist with 31 numbered items. They don't get the source code, and they don't need it. If support stops, they keep using what's installed. They aren't suddenly responsible for a codebase they didn't write.

The level of formality is different from a process-only engagement. The principle is the same.

Why this matters to the client

Owners and CFOs are sometimes nervous about hiring outside help for reasons that have nothing to do with the work itself. The fear, named plainly, is: what if the person who built this disappears?

The honest answer for most engagements is: you have a problem. The new procedure lives in the consultant's head. The software lives on a server nobody else knows how to maintain. The shortcut that saved you ten hours a week is documented in a Slack message from six months ago.

Designing for departure inverts that. The work product is decoupled from the consultant's presence. Your processes keep running. Your software keeps updating. Support pauses if I'm not around, but nothing breaks.

Why this matters to the consultant

It feels like leaving money on the table. It isn't.

A clean exit means the next engagement starts clean, without the previous client's emergencies bleeding into the calendar. A repeatable departure model means I can run more engagements. And the client who knows they can survive without me is more likely to stay because they want to, not because they're stuck.

The shape of an engagement that ends well is different from one that drifts. It has a defined deliverable, a written exit plan, and an artifact you can hand the client that says "here's what to do when something breaks and I'm not available." That artifact is the difference between consulting and rent-seeking.

A question to ask

If you're hiring outside help, whether for accounting work, a process problem, a software build, or just having someone walk through your operation and tell you what they see, ask early: what happens when you're not here anymore?

If the answer involves written documentation, a clear handoff, and a system you can run yourself, you're working with someone who has thought about this. If the answer is "well, you can always call me," that's worth knowing before signing.

The right answer is the boring answer. A documented exit, a system that keeps running, and a phone number you don't have to dial. That's what built to leave looks like.

← Back to all posts