Three calls landed on my calendar in one day, and together they made the same argument from three directions. Two of the calls were good for my agency. The third was aimed straight at my own operations. All three were about the same mistake: building a business on a single point of failure and assuming today’s stability extends into next quarter.
The first call was a client who had hired a freelancer from Poland. The work started well. Then the freelancer simply faded. There was always a reason, a family problem, a holiday, a promise to get to it next week, delivered with friendly messages full of smiley faces. The chat history my client showed me was warm and completely empty of finished work. Months of time gone, money spent, and the job still open.
The second call was a stable company doing around $3 million a year. They had one developer, and he had been good. Then they told him they were migrating to another platform and would not need him in a few months. From that conversation forward, he was gone in every way except payroll. His attention went to his job search. For two months the company could not get even routine updates shipped on a site that still needed them.
The third call was mine. Mercury, the US financial platform we used for online banking, sent a message that our account would be closed. No negotiation, no meaningful explanation, just a date. That account was how I paid my team.
MageCloud Risk Note
The Redundancy List I Keep Now
PEOPLE
A second developer who knows the stack
Not a bench warmer. Someone who has shipped real work in your codebase within the last quarter and could take over mid-sprint.
MONEY
A second bank account at a second institution
Operating capital split so that one compliance algorithm at one fintech cannot stop payroll. I learned this one personally.
VENDORS
A named fallback for every critical service
Hosting, payments, email. You do not need to use the backup. You need to know exactly how fast you could.
Paul Ryazanov · MageCloud · lessons priced in real downtime
Why Single Points of Failure Feel Safe Until They Fail
Every one of these failures looked like efficiency the day it was set up. One trusted freelancer is cheaper than a team. One developer who knows everything is faster than two who share context. One bank with a slick interface is simpler than two with paperwork. The efficiency is real, and it is exactly why the exposure builds quietly. Nobody audits an arrangement that is working.
What I have noticed is that the failure modes are rarely dramatic. The freelancer did not quit. He just stopped finishing. The developer did not resign. He just stopped caring. The bank did not collapse. It just sent an automated message. Single points of failure mostly do not explode. They dissolve, and by the time the dissolving is visible you are already inside the outage. The same pattern drives the daily monitoring stack I run on every store, because silent failure is the default failure mode of everything in this business.
What Redundancy Costs, and What It Does Not
The objection to redundancy is always cost, and the objection is mostly wrong. A second bank account costs an afternoon of setup. A documented runbook that would let a new developer take over costs a few hours of writing and pays for itself the first time anyone is on holiday. A relationship with a second development resource costs a small real project once or twice a year, money you would likely spend anyway on work your primary team is too busy for.
The expensive version of redundancy, keeping two full teams or duplicating infrastructure nobody uses, is a strawman. The working version is thinner: a second key that turns, tested occasionally. From the founder’s side of the table, the question is not whether you can afford the backup. It is whether you can afford the two months the $3M company spent unable to touch their own website.
The Uncomfortable Part: You Are Someone’s Single Point of Failure Too
Run the lens the other way. If your agency disappeared tomorrow, what happens to your clients? We support around 140 stores, and that responsibility is exactly why client infrastructure should live in accounts the client owns, not ours. An agency that makes itself impossible to replace has made itself a liability wearing a partnership badge. The honest version of this business is to be easy to fire and worth keeping. That structure protects the client from us and, just as honestly, protects us from becoming the kind of vendor that holds relationships together with switching costs instead of work.
Being Protected Now Does Not Mean Protected Tomorrow
The Mercury closure was the lesson that stuck, because it was the one where I had done nothing wrong. No missed payments, no policy breach I could identify, just a risk algorithm somewhere deciding our account no longer fit. Everything about our banking was fine right up until the message arrived. That is the property all three calls shared. The freelancer was fine until he was not. The developer was loyal until the day he had a reason not to be. The account was open until it was closing.
Do not take unnecessary risks with the boring plumbing of your business. An extra developer who knows your stack, a partner you can call in an emergency, a second bank account with a month of payroll in it. Set them up while everything is working, because that is the only time you can. If you want a second pair of eyes on where the single points of failure sit in your own setup, get in touch. It is a shorter list than you fear and a longer one than you hope.