6 Single Points of Failure Your Product Cannot Survive

Here’s an uncomfortable exercise: name every system your business depends on, then name the second person who could keep each one running tomorrow morning if something happened.

For most products, that second name doesn’t exist. The code, credentials, deployment steps, run cost, and the reasoning behind decisions nobody wrote down all sit with one person, and none of it surfaces until that person is unreachable.

AI didn’t create that risk. It made products cheap enough to start that far more companies now carry it without ever deciding to.

One Person, One System, No Backup

Small teams are no longer a small-company story. They show up in large organizations too, wherever one person owns one system.

“With AI, we’re going to start having smaller and smaller teams,” said Doug Compton, Director of AI Engineering at Slingshot. “Even in a large company, you can end up with one-person teams or one-person projects. That’s the dilemma.”

The quality trade-off is structural. On a normal team, a second developer reviews the work before it ships, and that review catches what the author cannot see.

“That single developer has to be a jack of all trades, and they’re probably a master of none,” said Chris Howard, President of Slingshot. “To create a secure, growth-capable solution, you need an architect. You need a few different mindsets and points of view to make sure that what’s coming out the door is ready for prime time.”

Then there’s the simplest version of the problem: one developer takes a vacation, loses internet for a few hours, or takes another job. Your product is down, and nobody else can reach the steering wheel.

What Walks Out the Door With the Developer

Ask most executives where their product dependency lives, and they will say the code. That’s only the first item on the list.

Credentials come first in practice. If one person holds the login required to deploy, every release waits on that person being reachable and cooperative. Recoverable, usually. Expensive and slow, always.

The second one is worse. “The one dependency that scares me the most is if the source code only lives on that person’s computer. They weren’t using GitHub, and then they left,” Doug said. “Now the company has zero source code. Depending on the language, you might be able to reverse engineer it, but if it’s compiled, you could be missing it altogether.”

Deployment is the quiet third. Plenty of systems require several machines to talk to each other in a specific order, with specific configuration. “AI is great at running on your computer and looking at the code on your computer,” Doug said. “But once a deployment relies on multiple machines, the AI probably doesn’t (and probably shouldn’t) have access to those other machines. If your deployment is more complicated than copying files up, that becomes a real problem after the person leaves. You could even break production trying to deploy it.”

The Run Cost Nobody Else Can See

Here’s a question worth asking before your next board meeting: what does this product cost to run every month, and is there only one person who can tell you?

“The cost to run your product is something the developer knows and other people may not,” Chris said. “In the context of AI, that dev may have some idea of the number of tokens required and how verbose the whole process is. The business owner won’t realize those things until the product is live; they could be pricing for something completely incorrect.”

Read that as a pricing problem, not a technical one. If the person who understands your unit economics leaves before you do the math yourself, you find out your margin is wrong after customers are already on the plan. In AI-heavy products, where per-transaction cost scales with usage instead of staying fixed, that gap gets expensive fast.

The fix costs you one conversation: ask what the system costs to run at current volume, then at ten times current volume. Write the answer down somewhere that isn’t a person’s memory.

Backups and Infrastructure Fail Quietly, Then Permanently

Most single points of failure give you time to recover. But a couple together doesn’t.

“There are instances where AI has taken down production,” Doug said. “In one case I saw, the production server was misconfigured; the production database sat on the same hard drive as the backups. Someone erased the drive, losing all production data and all backups. If your lone developer is also in charge of setting up infrastructure and that isn’t their strong suit, you could lose all of your data.”

That gap between inconvenient and unrecoverable is the one worth understanding before you need it. “Losing your backups could kill the product outright,” Doug said. “If the data is gone, you’ve lost more than the data. Your customers lose faith in you, and there’s no easy way to earn that back. Losing the source code sits right behind it, because recreating a system from scratch takes months, sometimes years.”

Chris landed somewhere totally different. “The one that would end it for me is security. If you launch with a vulnerability and get hacked, that damages the product and could hurt your whole company. On top of fixing the vulnerability, you have to rebuild trust in your app. You don’t always get to recover from that one.”

Compare that against the rest of what can go wrong. Locked credentials, undocumented deployment steps, and decisions nobody wrote down all cost you time and money, and time and money are survivable. Lost data, a missing codebase, and a public breach are a different category entirely.

AI Fills Part of the Gap, and Widens Another

AI genuinely helps here, which is why this problem is easy to underrate. Inheriting an unfamiliar codebase used to be a slow archaeology project. Now it’s a research task you can run in an afternoon.

“Before AI, you just spent a lot of time reading the code and working to understand it,” Doug said. “With AI in the picture, it can do that research for you. It creates documentation, sequence diagrams, flow charts of how the system works. It makes it a whole lot easier.”

Access changes too. “If the business owner has access to the code, they can lean on AI to ask questions that in the past would have had to go through the developer,” Chris said. “Used correctly, AI makes that better.”

Here is the catch: AI can tell you what the system does, but it can’t tell you why. “AI only has a limited memory of what happened in the past, unless it’s thoroughly documented somewhere,” Doug said. “It might re-implement the same thing a customer wasn’t happy about, or repeat a decision that shouldn’t be replicated.”

Chris put the same gap in business terms. “Unless you have documentation to go along with the code, you never really know why certain decisions were made,” he said. “You don’t know what’s important and what’s not; you only know what was built. You don’t know if it hit the mark as far as what the business needed.”

That is the part AI inherits rather than solves. Your institutional memory is only as good as what somebody bothered to write down.

The Red Flags, and the Cheap Fixes

Single points of failure rarely announce themselves, but they do leave traces. Red flags are out there if you know what to look for.

Start with who built it. If the person maintaining your product moved from the business side into development, they may never have been taught source control, backups, or deployment hygiene. Hence, the gaps stay invisible to them, too.

Then check what you can state about it yourself, starting with the monthly run cost. And finally, the simplest test of all: sit down and click through the product start to finish. If you have never watched it work end to end, you don’t actually know what state it’s in.

The good news is that fixing those red flags is cheaper than the exposure. “Have standards,” Doug said. “Identify a source control provider and require that it gets used. Set up continuous integration and deployment so releases are automated and documented. Even on a single-developer project, pull in another developer to review code to make sure things are done properly. And consult experts on infrastructure and backups.”

“Anyone can vibe code an application and deploy it to Vercel or another host, and IT has no idea it exists,” Doug said. “A non-developer in a department builds something, the team relies on it heavily, and nobody has oversight. That’s a problem waiting to happen.” His fix: keep a log of all the software your company is using and has deployed.

Chris pushed on visibility and containment. “Have a demo every week or two, so you stay close to what’s being built.” 

The Risk You Accept Should Be the Risk You Chose

Nothing in this conversation required a bigger team. It required knowing where your product actually depends on one person, and deciding on purpose which of those dependencies you are willing to live with.

Source control, automated deployments, an outside reviewer, a real backup, a known run cost, and a standing demo. Every item is cheap compared to rebuilding a codebase from scratch or explaining lost customer data.

AI didn’t create this problem. It made one-person products so easy to start that far more companies now carry the risk without ever noticing they picked it up.

The question isn’t whether you have a single point of failure. It’s whether you can name it before it names itself.

Slingshot