Founder dependency in technical diligence: what to ask

Why this question comes up

A startup can have clean code, working servers, and paying users, yet still carry a fragile risk: one person knows how everything actually works. That person is often the founder.

If the founder is the only one who can deploy, fix production, explain edge cases, or trace a customer issue to the right service, the business runs on memory more than process. That is why founder dependency comes up so often in technical diligence.

Buyers, investors, and partners are not just checking whether the product works today. They want to know whether it keeps working if the founder gets sick, takes a holiday, or leaves the company.

Code alone does not answer that. A repository can look tidy while the real operating knowledge lives in one person's head. Teams usually discover this at the worst time: a release stalls because nobody knows the deploy order, or an outage lasts four hours because the founder is asleep and nobody wants to touch production.

When one person holds most of the context, the same problems show up again and again. Releases slow down because others wait for approval. Incidents last longer because nobody knows who should act first. Product changes cause regressions because hidden rules were never written down. Hiring gets harder because new people cannot learn from a clear system. Customers start to notice that simple fixes depend on one calendar.

Picture a six person SaaS startup. The founder wrote the billing rules, set up the cloud account, and still handles late night alerts. On paper, that company has a team. In practice, one person owns the map, the tools, and the spare keys.

That is why diligence calls ask blunt questions. Who can deploy today without asking the founder? Who leads an incident at 2 a.m.? Who can explain why enterprise customer A sees different behavior from customer B? Those answers show how much of the company is transferable and how much is still personal knowledge.

The good news is that this risk usually drops fast once the team writes things down, shares access, and practices routine work without the founder in the loop every time.

Who can deploy without the founder

Deployment is often the first place this risk shows up. If one person is the only path to production, the release process is fragile even when the product works well most days.

A buyer or investor will usually ask for names, not job titles. "Our engineer can deploy" is weak. "Anna and Victor can release the app, Maria can approve a hotfix, and any of the three can roll back" is much stronger. That answer shows shared ownership and clear limits.

Four questions matter here:

• Who can push a normal release to production today?
• Who can approve that release?
• Who can roll back if login, billing, or another core flow breaks?
• Who has the passwords, tokens, and cloud access needed to do all of that?

The last point trips up a lot of teams. A startup may say two engineers can deploy, but the access still lives in the founder's personal GitHub account, cloud account, or app store profile. That is still single person risk. If the founder loses access, gets sick, or goes offline during travel, the team can get stuck at the worst moment.

The best test is simple: can the team ship during the founder's week off? Pick a small release. Let someone else approve it. Make sure another person can watch the deploy and roll it back without asking the founder for a code, password, or missing bit of context.

The fix is usually boring, which is good. Move access into company owned accounts. Write a short deploy runbook. Define who approves what. Make sure at least two people have done a live deploy recently.

If the founder is still the only person who can deploy, say that clearly and show the plan to change it. A small startup does not need a huge release system. It does need one backup person who can ship safely on a normal Tuesday afternoon without making a phone call.

Who owns incidents when something breaks

Outages expose founder dependency fast. A team may look fine on a normal day, but an incident shows who actually runs the product under pressure.

Start with one plain question: if the site goes down tonight, who is in charge? Diligence gets much clearer when the company names one person instead of giving a vague answer like "the team." That person does not need to fix every issue alone, but they should own the response until service returns.

Then map the first 15 minutes. Who gets the alert first? Who joins next? If the answer is still "the founder gets paged and decides what to do," the risk is real. A healthier setup is clear: the engineer on call checks the alert, another engineer joins if needed, and the founder steps in only for larger business calls.

Communication matters as much as repair work. During an incident, someone needs to write updates for the rest of the company, customers, or both. If nobody owns that job, engineers go silent, people start guessing, and a small incident can look much worse than it is.

A diligence call should get direct answers to four points:

• Who leads the incident from first alert to recovery?
• Who receives alerts first, and who joins next?
• Who posts updates while engineers work?
• Where is the written path for diagnosis, escalation, rollback, and recovery?

That written path can be short, but it should exist. Good teams keep a simple runbook with alert rules, service owners, rollback steps, contact names, and a rule for when to escalate.

A small startup does not need a heavy incident process. It does need one that works without the founder typing every command. If one engineer can follow the runbook, pull in the right people, restore service, and record what happened, the risk drops a lot.

When a founder says, "I usually handle incidents myself," treat that as a warning sign, not a badge of dedication.

Who knows the product logic

This is where the harder questions start. People are trying to learn whether the company runs on shared knowledge or on the founder's memory.

The code matters, but the real trouble usually sits around pricing rules, access limits, refunds, approval flows, and odd customer cases that piled up over time. A sharp question is this: if the founder disappears for a week, who can explain why one customer pays list price, another gets a discount, and a third keeps a feature after downgrading?

If nobody can answer without searching old chats, the risk is real.

Pricing rules deserve extra pressure because they get messy fast. A startup may begin with one clean offer, then add annual deals, trial extensions, old plans, manual credits, reseller terms, and promises made during sales calls. The founder often remembers why each exception exists. Diligence checks whether anyone else does.

Ask where those decisions live today. Strong answers are concrete. The team can point to product docs, ticket history, admin notes, support replies, and tests that show how a rule works. Weak answers sound like this: "Sam usually knows" or "we just ask the founder."

Support is a useful checkpoint. Pick a few issues that show up every month, such as plan upgrades, refund requests, or users who hit usage limits. Ask support to explain the rule in plain English. Ask engineering the same question. If the answers do not match, the problem is bigger than thin documentation. The team is operating with different assumptions.

You can test product understanding with one realistic case. Ask what happens when a customer changes plans in the middle of a billing cycle after already using more than the new plan allows. If product, support, and engineering give three different answers, the logic is still trapped in one person's head.

A good setup feels almost boring. The founder may know the history, but the team can explain the current rules, handle normal exceptions, and point to one source of truth when questions come up.

How to reduce single person risk step by step

Most teams do not solve this with a grand process. They solve it by making ownership visible and testing it in real work.

Start with a simple map of three areas: deploys, incidents, and product rules. Put one primary owner and one backup next to each task. If nobody can be the backup today, that gap is the first problem to fix.

A practical sequence works well:

1. Run one normal deploy without the founder touching anything. The founder can watch, but the team should prepare, deploy, verify, and roll back if needed.
2. Write down the ten product decisions people ask the founder about most often. Include pricing rules, permission logic, approval steps, and common edge cases.
3. Move access out of personal accounts and into team owned systems. That includes source control, cloud access, monitoring, CI or CD, domains, and the password manager.
4. Set up named owners for alerts and incidents. One person responds first, one person backs them up, and one person decides when to escalate.
5. Review the weak spots every week for a month. Small teams improve fast when they focus on one missing owner at a time.

The deploy test is usually the most honest step. A team may say, "anyone can deploy," then freeze when a migration fails or a config value is missing. That is useful. It shows exactly what needs documentation or training.

Shared access matters just as much. If billing, hosting, or production secrets live in the founder's inbox, the team does not own operations. They are borrowing them.

The incident plan can stay simple. Define who checks alerts, who can roll back, who talks to customers, and when the founder gets pulled in. The founder should be an escalation point, not the first person every alarm wakes up.

If the company is small, outside help can speed this up. Oleg Sotnikov at oleg.is works as a fractional CTO and often helps startups sort out handoffs like deploy access, incident ownership, and shared product knowledge before diligence. That kind of support is useful when a team needs a working process fast, not a pile of documents.

A simple startup example

A five person SaaS team looks healthy on paper. There is a founder who still writes code, two engineers, one designer, and one support lead. Revenue is growing, customers are happy, and releases go out every week.

Then diligence starts, and one pattern shows up fast. The founder approves every deploy, keeps the production secrets in a password manager only they use, and gets the late night alerts. When something breaks, the team waits for the founder to wake up, check logs, and decide what to do.

Product logic sits in the founder's head too. The engineers know the codebase, but they do not fully know why certain billing rules exist, why one customer gets a special workflow, or which shortcut will break reporting. The company can operate, but only while one person stays available.

Now imagine the founder goes offline for ten days. Nothing dramatic has to happen. Maybe they are sick, on a long flight, or buried in fundraising meetings.

A small release is ready, but nobody feels safe pressing deploy. A customer reports missing invoices. Support escalates it. The engineers can trace the bug only halfway because the founder wrote the original billing logic. An incident stretches from 20 minutes to six hours, not because the team is weak, but because ownership is fuzzy.

That is what investors notice. They do not see a bad team. They see a team with one choke point.

The good part is that this kind of risk often drops quickly. In two or three weeks, a team like this can move deploy access to at least two engineers, write a short incident runbook for the top failure cases, document unusual product rules in plain English, rotate incident ownership for smaller issues during business hours, and have one engineer shadow the founder on every release.

None of that requires a giant process project. The team just needs to make daily work less personal and more shared.

If the founder can step away for a week and releases still ship, incidents still get handled, and product decisions still make sense, the diligence conversation changes a lot. The company starts to look steady instead of fragile.

Mistakes that make the risk worse

The first bad assumption is simple: access is not ownership. A teammate may have production credentials, but that does not mean they can deploy safely, roll back a bad release, or judge whether an alert is noise or a real customer issue. If everyone still waits for the founder to approve the last step, the founder still owns the process.

Another common mistake is choosing one backup person and calling the problem solved. That looks fine on an org chart and falls apart in real life. If that person leaves, gets sick, or knows only part of the system, the team still has the same single person risk.

It gets worse when the backup learns only the mechanics, not the judgment. They may know which button to press, but not when to stop a release, when to roll back, or which customer workflows will break first. That gap usually shows up during incidents the team has never practiced.

Product logic often ends up in chat history, voice calls, and the founder's head. Teams tell themselves they will document it later. Later rarely comes. Then diligence starts, someone asks how billing exceptions work, and nobody can point to one clear answer.

Quick checks before the diligence call

A diligence call gets easier when you can answer a few plain questions without pulling the founder into every detail. Small gaps matter more than polished slides.

Start with proof that the team can ship without one person. If only the founder can deploy, the risk is obvious. A stronger answer is straightforward: two people have working deploy access, both have used it recently, and both know how to roll back if a release goes wrong.

A short checklist helps:

• Confirm that at least two team members can deploy to production and reverse a bad release.
• Show the incident rotation, with one named owner for each shift.
• Keep the main product rules in one shared document that the team updates.
• Send alerts to a team channel, pager, or incident tool, not only to the founder's phone.
• Ask a newer engineer to follow a basic runbook and note where they get stuck.

These checks are easy to verify. Open the access list. Open the incident schedule. Open the document that explains the product's sensitive rules, such as pricing logic, approval flows, or account limits. If that knowledge lives only in the founder's head, buyers and investors usually notice fast.

The runbook test is especially useful. Pick one common event, such as a failed deploy or a payment webhook error. Then have someone who did not build that part of the system read the runbook and talk through the first ten minutes of response. If they cannot do it, the document is not doing its job.

Teams also miss the alerting check. Plenty of startups have monitors, but the alerts still go to one inbox or one phone number. That turns every late night issue into founder dependency even if the rest of the team is capable.

What to do next

Start with the biggest gap, not the easiest one. If one person still holds the whole system together, fix the area that would hurt most if they were away for a week. That is usually deploys, incidents, or product rules that only live in the founder's head.

Pick one of those this month and transfer it for real. Do not settle for a chat or a loose promise. Have another team member do the work end to end while the founder stays quiet and takes notes on every place they get stuck.

A deploy handoff is a good first move because it is easy to test. Write the steps in plain language, give the second owner the right access, and let them run a normal release. If they pause to ask where a secret lives, which check matters, or when to roll back, the handoff is not finished.

Run the same test for incident response. Do one tabletop drill with a simple scenario, such as a failed release or a payment bug, and make the backup owner lead it. Then do one real handoff on a live deploy or an incident shift soon after, while the notes are still fresh.

Buyers and investors also want a simple owner map. Keep it short. One page is enough if it names who owns deploys, who leads incidents, who knows product logic for billing or permissions, who manages access, and who backs each person up.

This document does not need polish. It needs names, dates, and clear ownership. That alone cuts a lot of worry in a diligence call because people can see the company can operate without one founder doing everything.

One clean deploy handoff, one incident drill, and one owner map can change the whole discussion.