If Dave Gets Hit by a Bus, So Does Your Zapier Account

Somewhere in America right now, a five-person startup's entire lead pipeline depends on a Zapier workflow that one person built at 11 p.m. on a Tuesday. That person is on vacation next week. Nobody else knows what the workflow does, why it exists, or what breaks if the source spreadsheet gets renamed.

This is the bus factor problem, and in small teams it's not a hypothetical. It's Tuesday.

The Ghost in the Machine

Internal automations are the shadow IT of small companies. They get built organically — a Zap here, a Slack bot there, a Make scenario that syncs your invoicing tool to your CRM through a Google Sheet nobody was supposed to touch. They work brilliantly. That's the trap.

Because they work, they become load-bearing. And because they were built by one person, they're invisible to everyone else. The founder who built the onboarding automation doesn't document it for the same reason you don't document how to breathe: it's obvious. To them.

Then they leave. Or they get sick. Or they just forget, six months later, why the automation sends duplicate Slack alerts on Thursdays. Either way, the team is now reverse-engineering its own operations during a crisis.

Treat Automations Like Production Code

Software engineers solved this problem decades ago. The answer isn't more meetings — it's ownership discipline. Borrow it:

1. Name an owner for every automation. Not "the team." A human with a name. If they roll off the project, ownership transfers explicitly, like onboarding a new maintainer.

2. Write a one-paragraph spec. What triggers it, what it touches, what breaks if it fails, and who gets pinged when it does. This takes ten minutes per workflow. That's the whole ask.

3. Version your changes. Most no-code platforms now offer revision history — use it. If your tool doesn't, keep a changelog doc: what changed, when, why. "Tweaked the filter" is not a changelog entry.

4. Do a handover walkthrough. Record a 15-minute screen share of the owner clicking through the workflow and narrating it. Loom is fine. Future-you will treat this as a gift.

5. Run a fire drill. Once a quarter, have someone who didn't build the automation trace through it cold. If they can't figure out what it does in fifteen minutes, the documentation failed — better to learn that now than during an outage.

The Deeper Point

There's a philosophical question underneath the checklist: is your company's operational knowledge an asset or a personality trait? If everything your business runs on lives in one person's head, you haven't built systems. You've built a dependency with a heartbeat.

The teams that scale cleanly aren't the ones with the most automations — they're the ones where any two people could explain any workflow. That's not bureaucracy. That's what lets a small team move fast without being one sick day away from operational amnesia.

Document the ghost in the machine before it haunts you. Dave will appreciate it, too.