I Am the Only Person Who Knows How It Works, and That Is a Problem I Built

What happens to my clients if I am unreachable for a month?

For the websites, very little. For the automations, quite a lot. A Webflow site keeps serving pages without me. A running automation with credentials, branching logic, and a sync between two systems needs somebody who understands it the moment anything changes, and for several of the things I have built, that somebody is only me.

I work alone. Over six years, seventy plus projects and twenty five plus clients, that has been mostly an advantage. It is also how I quietly accumulated a liability that nobody bought and nobody priced, and that only becomes visible on the day it matters.

This is an honest look at that problem, including the parts I have not solved.

What is the bus factor problem for a solo practitioner?

Bus factor is the number of people who would have to become unavailable before a system could not be maintained. For most of what I have shipped, that number is one. The work functions perfectly while I am reachable, and its maintainability is entirely dependent on a single person continuing to be reachable.

The uncomfortable part is that clients rarely ask about it. They ask about delivery dates, scope, and price. Nobody has ever asked me what happens to their lead routing if I am out of contact for a fortnight, which means the risk sits entirely on their side while being entirely invisible to them.

It is also not the client's job to ask. They hired someone competent to solve a problem. Noticing the structural risk in the arrangement is my responsibility, and for a long time I did not notice it because everything was working.

Why is this worse with automations than with websites?

Because a website degrades gracefully and an automation does not. If nobody touches a site for six months it carries on serving the same pages. If nobody touches an automation for six months, an API changes, a credential expires, a field gets renamed, and the thing silently stops doing what it was built to do.

The Ajust work is the clearest example in my own practice. That runs on Airtable synced through WhaleSync, and it has delivered more than twenty five thousand cases, helped more than four hundred thousand people, and saved more than fifty thousand hours. The scale is exactly what makes the single-person dependency uncomfortable rather than theoretical.

The same logic applies to the CRM side. Kismet Health runs HubSpot fed through Zapier, and the moving parts there are not conceptually difficult. They are just specific, and specific knowledge lives in one head unless you do something deliberate about it.

Why is documentation not actually the answer?

Because documentation records what a system does, and the expensive knowledge is why it does it that way. Anyone can read a workflow and see three branches. Nobody can read it and know that the second branch exists because of a data quirk that showed up once in testing and has never recurred.

I do write runbooks, and I think they are worth the time, which is why I wrote up what belongs in a runbook before you ship. But I have stopped pretending a runbook transfers understanding. It transfers procedure, which is enough for the routine cases and not enough for the ones that actually need a human.

The version that comes closest to working is writing down decisions rather than descriptions. One line per non-obvious choice, saying what was rejected and why. That is the artifact I would want if I inherited somebody else's system, and it is the one almost nobody produces, including me on my worst weeks.

What does a client deserve to be told about this?

The truth, in one sentence, before they commit. Something close to: this will be built and maintained by one person, here is what happens if that person is unavailable, and here is what it would cost to reduce that risk. Then let them decide.

I have found that saying it plainly does not lose work. It changes the conversation from a vague assumption of institutional backing to a specific, priced decision. Some clients shrug, because the system is not critical enough to worry about. Some ask for the mitigations, and those become a legitimate line in the scope.

What loses trust is the opposite: letting a client assume there is a team, because the work is good and the invoices look professional. I do not describe my practice as anything other than what it is, and this is one of the places where that discipline has a real cost and is still correct.

What mitigations have actually worked?

Three that are cheap, and one that is not. The cheap ones are client-owned credentials, client-owned accounts, and a written decision log. The expensive one is building the system simpler than I could have built it, which costs capability up front and buys maintainability forever.

Credential ownership matters more than anything else. If every connection runs through accounts the client controls, then the worst case is that they need to find someone new, which is a solvable problem. If the accounts are mine, the worst case is that they need to find someone new and rebuild from nothing, which is a different order of disaster.

Simplicity is the mitigation I underrate most often. Every clever branch I add is a thing that needs explaining later, and clever branches are what a solo builder produces when nobody is reviewing the work. Constraining myself to what a competent stranger could follow is the most effective handover preparation I have found, and I wrote about the mechanics of that handover in documenting an automation handoff for clients.

Does this change what work I should take on?

It should, and it has. I am now more cautious about taking on systems that would become load-bearing for a business while remaining understood by one person. That is not a refusal to build important things. It is a refusal to build important things in a way that makes me a permanent single point of failure.

The filter I apply is whether the client could survive replacing me on three weeks notice. If the answer is clearly yes, I build what makes sense. If the answer is no, then either the build gets simpler, the documentation gets serious, or I say that the engagement needs a second person in it who is not me.

This has made me turn down a small number of otherwise attractive projects, and I do not fully enjoy that. It is still better than the alternative, which is taking the work and quietly hoping that nothing happens to me for the next three years.

Is subcontracting the fix?

Partly, and less than it looks. Bringing in a second person creates a second person who has seen the system, which is genuinely valuable. It does not create a second person who understands why it is built that way, unless they were there for the decisions.

There is also an honest tension between subcontracting and the reason clients hire a solo practitioner in the first place. They are buying direct access to the person doing the work. Adding a layer changes the product, and pretending otherwise is a slow way to lose the thing that made the practice worth hiring. I worked through that trade-off in whether a solo consultant should subcontract overflow work.

Where subcontracting does help is as a deliberate, paid review rather than as capacity. Someone competent spending a day reading a system and asking why produces both a second reader and a much better decision log, because the questions they ask are the ones the documentation was missing.

What would I do differently from the beginning?

Write the decision log from day one of every build, in the same file as the work, and treat it as a deliverable rather than as notes. It costs a few minutes per decision while the reasoning is fresh, and reconstructing it afterwards is close to impossible.

I would also set up every integration in the client's accounts from the first connection, rather than building quickly in my own and migrating later. Migrating later is one of those tasks that stays technically easy and permanently unscheduled, and it is exactly the thing you do not want to be doing under pressure.

The third thing is that I would price the maintainability work explicitly rather than absorbing it. On fixed fees, invisible work gets squeezed by definition, and the first thing to get squeezed is the part that only pays off in a situation everyone hopes never happens.

What should you do next?

If you run a solo practice, pick the client system whose failure would hurt most and ask honestly how long a competent stranger would need to take it over. If the answer is longer than a week, you have found something worth fixing this month.

If you are the client in this arrangement, ask your contractor the direct question. Whose accounts hold the credentials, what is written down, and what happens if you cannot be reached for a month. A good answer is reassuring and a bad answer is worth knowing now rather than later.

If you want a second opinion on how exposed a particular build makes you, tell me what it connects and who owns the accounts. I will tell you honestly where I think the risk actually sits. Let's chat.