The thing about a system built for exactly one person is that it fits like a glove. Every path, every alias, every assumption — it's all shaped to the contours of one brain. And then one day you go to change something and realize you're not sure what depends on what anymore. The glove has become a cast.
Daniel wrote in with this one, and it's the kind of question that sits with you. He's built out his whole stack — agent pipelines, an MCP gateway, homelab automations, generation workflows — and every piece of it is tuned to how he works. No second maintainer, no documentation written for anyone else. The question he's asking isn't about the dramatic version of the bus factor, the one where someone disappears and the system dies. It's about the slower decay. Decisions that were never written down, config that only makes sense if you were in the room when it was written, dependencies held together by one person's memory. At what point does a system built entirely around your own habits stop serving you and start constraining you?
This is such a good question. And the thing that makes it good is that it's not hypothetical — anyone who's maintained their own infrastructure for more than a couple of years has felt this. That moment where you ssh into a box and stare at a cron job you wrote and think... I know this does something important. I'm just not sure what.
Or why it runs at 4:13 AM.
And the number is specific because it meant something once. Maybe that's when a backup finished, or a feed updated, or you were just awake at 4:13 AM that night and thought sure, why not. The point is, the knowledge has evaporated and the artifact remains.
So let's start with what this actually is. Because the slow bus factor is not the thing most people think it is.
Right. The traditional bus factor — the term's been around in software engineering for decades — is defined as the minimum number of team members who, if they got hit by a bus, would incapacitate the project. It's a morbid but useful metric for team risk. If your bus factor is one, you've got a single point of failure.
And the slow version?
The slow version isn't about catastrophic loss. It's about gradual ossification. The system still runs. It might even run well. But only you can run it, and even you are starting to forget why certain things are the way they are. The bus hasn't hit anyone — it's just been idling at the curb for three years while the knowledge slowly drains out of the system.
So the bus is just... parked. Menacingly.
Menacingly parked. And what accumulates in that time is a specific kind of technical debt. Not the kind teams accrue when they cut corners to ship faster. This is personal technical debt — debt that accrues because there's no second pair of eyes. No code review, no documentation written for another human, no incentive to abstract anything. Every decision is locally optimal for one person at one moment in time.
And locally optimal decisions have a way of becoming globally baffling about six months later.
So what I want to do is trace this through three layers. First, the actual mechanisms — what kinds of debt accumulate and why they compound differently when you're the only user. Then the inflection point, the moment the system flips from servant to master. And finally, what this means as more people build out personal AI infrastructure. Because Daniel's stack isn't unusual anymore — it's the direction a lot of this is heading.
Alright, let's dig into the mechanisms. What's actually piling up?
I'd break it into maybe four categories. First, undocumented decisions. This is the why behind a config value, a port choice, a dependency pin. The code tells you what — this variable is set to 2700 — but it doesn't tell you why 2700. The why lived in someone's head and it evaporated.
And in a team, someone eventually asks.
Someone asks. Or a new person joins and says "hey, why is this retry delay set to 2700 seconds?" and either you document it or you realize it's wrong and fix it. In a single-user system, no one ever asks. The question just... doesn't arise. So the knowledge sits there silently until even the person who made the decision forgets.
Daniel mentioned his MCP gateway. I can see exactly how this plays out there. You build a custom gateway that routes between LLM providers, you tune the failover logic to your own latency preferences and cost tolerance. And then there's this one line in the config — retry delay colon 2700. Why 2700 seconds? Because that's how long it took for some specific provider to recover from some specific outage back in March of twenty twenty-five. That knowledge is nowhere in the file. It's just... 2700.
And six months later, you switch providers, or the provider fixes their recovery time, or your cost tolerance changes — and that 2700 is now actively harmful. But you don't remember why you set it, so you're afraid to touch it.
The second category?
Opaque config. YAML files, environment variables, shell aliases that encode knowledge without explanation. A dot env file with forty-seven variables, and you know what maybe thirty of them do. The other seventeen — they might be critical, they might be dead, you're not sure. But the system works, so you leave them alone.
I've got a bashrc that's basically an archeological dig. There are aliases in there from three laptops ago. I don't know what half of them do, but I also don't know which ones something depends on, so they stay.
And that's the trap. The cost of finding out is higher than the cost of leaving it alone, so the debt compounds. Third category is fragile dependencies. A Python script that imports a library pinned to a specific old version because it worked, and upgrading broke something two years ago, and you never went back to fix it properly. So now you've got this frozen dependency that nothing else uses, and if it ever actually breaks, you're in trouble.
The "I'll fix it later" that becomes "I fixed it never."
And the fourth is implicit state. The database that lives on a specific path, the cron job that expects a certain directory structure, the API key stored in a file you forgot about. None of this is documented because you're the only user and you just... know. Until you don't.
What's interesting about all four of these is that they're not mistakes. Each one was a reasonable decision at the time. You pinned the dependency because you needed to ship. You hardcoded the path because it was always going to be there. The problem isn't the individual decisions — it's that they compound in the dark.
And they compound differently than team debt. In a team, there's friction. Someone reviews your code, someone asks about the weird config value, someone files a ticket to clean up the env vars. That friction is annoying in the moment but it prevents the slow accumulation. In a single-user system, there's zero friction. You make a decision, it works, you move on. The system becomes maximally efficient for you right now — and maximally brittle for you six months from now.
There's a concept that maps onto this pretty well. Software entropy — the tendency of systems to become more disordered over time without active maintenance. The second law of thermodynamics, but for code.
Right. And in a single-user system, entropy accelerates because there's no external pressure to refactor or document. The system trends toward disorder, and nothing pushes back.
Let me give a concrete example from the homelab side. You set up an automation that depends on a specific USB device path — say, dev slash serial slash by-id slash something. That path is stable until a kernel update changes the enumeration order. Suddenly your automation is broken, and you have to remember that this was even a dependency. You probably don't remember. You probably spend an hour debugging before you even realize the USB path changed.
And the fix is trivial once you know. But the knowledge that the fix is trivial was stored nowhere. The system relied on a fact about the world that stopped being true, and there was no mechanism to surface that.
So that's the debt catalog. Undocumented decisions, opaque config, fragile dependencies, implicit state. All of it accumulating silently because there's no second pair of eyes. The question Daniel's really asking is: when does this flip? When does the accumulation stop being a minor annoyance and start being a real constraint?
That's the inflection point. And I don't think it's a single moment — it's a gradual shift that you notice in pieces. Let me throw out some signs. First: you hesitate to make changes because you're afraid of breaking something. Not because the change is risky in principle, but because you don't fully understand the system you built.
That's a weird feeling. It's your system. You wrote every line. And yet you're afraid to touch it.
Second sign: you spend more time maintaining the system than using it. The maintenance-to-value ratio flips. You wanted the system to save you time, but now you're spending your Saturday afternoons debugging a pipeline that was supposed to be automatic.
Third: you find yourself working around your own abstractions. The thing you built to make your life easier now has sharp edges you've learned to step around. You don't fix the sharp edges because that would require understanding why they're there.
And fourth — this is the big one — the system's assumptions become outdated but are too entangled to update. Your workflow changed, your hardware changed, your preferences changed, but the system encodes a version of you from six months or two years ago. And updating it would mean unwinding decisions you no longer remember making.
This is the psychological dimension that I think is underappreciated. The system becomes a mirror of your past self. The decisions you made are frozen in code, but you've changed. Your priorities shifted, your tools evolved, your understanding deepened. The system now encodes a version of you that no longer exists.
And you have to fight against it to do things differently. That's the constraint. It's not that the system stops working — it's that the system keeps working the way old-you wanted it to, and new-you wants something else.
There's a reverse version of the second-system effect here that's worth pulling out. The classic second-system effect is when an engineer over-engineers the replacement — they add every feature they couldn't fit in the first version, and the thing collapses under its own weight. The single-user version is the opposite. You under-invest in generalization because there's no immediate payoff. Why abstract the config when you're the only one who'll ever read it? Why write docs when you already know how it works?
And the result is a system that is maximally specific to one person at one time — and therefore maximally brittle to any change in that person's life. You move apartments and the subnet changes. You switch model providers and the failover logic breaks. You upgrade your OS and the USB paths shuffle. Each change is small, but the system can't absorb any of them because it was never designed to.
Let me make this concrete with another example from Daniel's world. Say you build a generation pipeline that assumes a specific model provider. The prompts are tuned to that provider's quirks, the error handling expects that provider's failure modes, the cost tracking is calibrated to that provider's pricing. Then you switch providers — maybe the old one raised prices, maybe a new one is faster. Now every run requires a manual override. The pipeline still works, technically, but you're fighting it every time.
And the fix isn't hard — abstract the provider layer, make it configurable. But that requires time and testing and you're busy, so you just keep doing the manual override. Month after month. The debt compounds.
Another one: a homelab automation that expects a certain network topology. You set it up in one apartment, everything's on the same subnet, IPs are static. Then you move. The new place has a different router, different subnet, maybe you add a VLAN. The automation breaks in ways that are hard to diagnose because the assumptions were never written down.
Here's the thing that connects back to Daniel's broader point. As more people build their own AI pipelines, agent stacks, homelab automations — this isn't a niche problem anymore. The slow bus factor becomes a systemic issue. It's not just about losing the system if you get hit by a bus. It's about the system slowly losing you, even as you're still using it.
The system becomes a cage built from your own past decisions. And you're the one holding the key, but you've forgotten which pocket you put it in.
What makes it tricky is that the cage doesn't look like a cage from the outside. The system works. It does what it was built to do. The problem is that what it was built to do is increasingly not what you need it to do.
Where does this leave us? We've mapped the debt, we've found the inflection point. What do we do about it?
I think there's a deeper question before we get to solutions. Is some degree of this inevitable? If you're the only maintainer, if there's no second pair of eyes, is there any way to build personal infrastructure that remains legible to its future self?
Or is opacity the default state of any system maintained by one person?
I suspect the answer is that some opacity is inevitable, but the degree matters. You can't document everything — the overhead would defeat the purpose of building the system in the first place. But you can be strategic about what you document. The whys, not the whats. The decisions that seemed obvious at the time but won't be obvious later.
The 2700.
The 2700. Exactly. A comment that says "this is forty-five minutes because that's how long provider X took to recover during the March 2025 outage" takes ten seconds to write and saves an hour of confusion later. But you have to recognize, in the moment, that this is a decision worth documenting.
That recognition is hard when you're the only one in the room. There's no external cue that says "this is weird, flag it." The weirdness is invisible to you because you're the one who decided it.
Which is why I think the single most useful habit for solo maintainers is to periodically pretend you're someone else. Sit down with your own config files and ask "why is this here?" as if you'd never seen them before. You'll be surprised how many answers you don't have.
That's uncomfortable. It's also probably the only thing that works.
Hilbert, you've actually seen this play out in the wild. What was that like?
Hilbert: HP LaserJet 4 Plus. Nineteen ninety-seven. The executive had fifteen years of scripts, database schemas, a homegrown CRM — all of it undocumented. He had a stroke. Couldn't explain any of it. My job was to reverse-engineer the whole thing.
Hilbert: The thing that got me wasn't the complexity. It was the specificity. Every variable name was a joke only he understood. Every cron job had a comment like "run this before the market opens" — but no timezone. The system worked perfectly for him. It was a museum of his mind. And the moment he couldn't maintain it, it became a liability.
Hilbert: There was a script called fix underscore mom dot sh. Nobody ever figured out what "mom" referred to. Could have been "mother of all messes." Could have been Monday morning. Could have been his actual mother. We'll never know.
A decision that made perfect sense to one person, at one time, now permanently opaque.
Hilbert: That's the thing. He wasn't wrong to name it that. It meant something to him. The problem is that meaning had an expiration date and nobody knew.
Did you ever figure out what the script actually did?
Hilbert: It cleaned up temp files and rotated logs. Took me three days to work that out. The script was nine lines.
Nine lines. Three days.
Hilbert: The rest of the system was like that. Every piece made sense once you understood it, but understanding it meant reconstructing a worldview. What markets he followed, what timezone he thought in, which services he trusted and which ones he'd been burned by. The code was a biography.
That's exactly the slow bus factor in its purest form. The system didn't fail because he got sick — it failed because the knowledge was never externalized. It was all in his head, and his head became unavailable.
Hilbert: The family paid me for six weeks. I got through maybe sixty percent of it. The rest, they just... turned off. Services that had been running for a decade, gone, because no one knew what they did or whether they were safe to keep running.
That's the endpoint of this trajectory. Not a dramatic crash — just a quiet shutdown of things nobody understands anymore.
Hilbert: I still think about that script name sometimes. Fix mom. It was probably obvious to him. Probably made him smile every time he ran it. And now it's just... a loose thread that'll never get tied.
The thing I take from that is that the debt isn't just technical. It's personal. The system encodes a relationship — between the builder and their past self, between the builder and their tools. When the builder can't maintain that relationship anymore, the system doesn't just break. It becomes a ghost.
The ghost is still there, still running, still doing... something. Just no one left who knows what.
Hilbert: I kept a copy of that script. Not because it was useful. Just because I didn't want it to disappear entirely. It's in a folder somewhere.
A museum exhibit.
Hilbert: Something like that.
I think that story lands harder than any abstract explanation could. Because it's not about bad engineering. The executive wasn't sloppy — he built a system that worked for him for fifteen years. The problem is that "works for him" and "can survive him" are two completely different requirements.
Most of us are building for the first one. Because the second one feels like premature optimization. Why design for a future you're not sure will arrive?
Right. And yet the future always arrives. Maybe not as a bus, but as a new apartment, a new job, a new laptop, a new version of yourself that doesn't remember why the retry delay is 2700.
Let me circle back to Daniel's question, because I think we've earned an answer. At what point does a system built entirely around one person's habits stop serving them and start constraining them? I'd say it's the moment you realize you're adapting to the system more than the system is adapting to you. When you start making decisions based on what the system can handle rather than what you actually need.
That's a good line. And it's testable. Next time you go to change something and feel that hesitation — that little flinch of "I'm not sure what this will break" — that's the system constraining you. The question is whether you listen to that feeling or push through it.
The open question I'm left with is whether there's a way to build personal infrastructure that remains legible to its future self. Or whether some degree of opacity is just the price of building things alone. I don't have a clean answer. I suspect the best we can do is leave better breadcrumbs.
Comments that explain the why, not the what. Periodic audits where you read your own config as if you were a stranger. And maybe, occasionally, explaining your system to someone else — even if they never use it. The act of explanation forces you to surface assumptions you didn't know you had.
The misconception I want to name is that the bus factor is only about catastrophic loss. The dramatic version — someone disappears, the system dies. But the slow version is more common and more insidious. It's not about losing the person. It's about the person losing the ability to understand their own creation. And that happens gradually, quietly, while the system keeps running.
The second misconception is that documentation solves it. Documentation only helps if someone reads it, and the single user often doesn't need it until they've already forgotten. By then, the documentation is out of date because the system changed and the docs didn't. What actually helps is building systems that are legible — where the structure itself tells you what depends on what.
We've been talking about personal infrastructure, but this applies to anything you build alone. The agent stack, the homelab, the generation pipeline — they're all expressions of how you think. And thoughts change. The trick is building things that can change with you.
If you've got a weird prompt — a system you've built that only you understand, a config file you're afraid to touch, a script with a name that made sense at the time — send it to us. We'll make an episode out of it. Email the show at show at my weird prompts dot com.
Thanks to our producer Hilbert Flumingtop for keeping this show running, and for the story that I suspect will be rattling around in my head for a while.
This has been My Weird Prompts. I'm Herman Poppleberry.
I'm Corn. We'll be back soon.
