A cofounder leaving with the only deployment login is an operational failure, not a personnel detail. A company can continue only when access, ownership, and recovery paths are designed before someone walks out.
At 10:14 on Thursday morning, Lina was sitting in a small office in Accra with one hand on her phone and the other on a customer email. Their pilot needed a production fix before Friday. The cofounder who owned the deployment account had left the company that week, and every reset request still went to his old address.
The customer was waiting. The fix was ready. The team could see the code, review the pull request and run the application locally. They could not put the change into production. By lunch, the pilot might be delayed. By Friday, the customer could decide the team was too risky to continue with.
Lina spent the next hour checking old password managers, shared documents and a laptop nobody had opened since the previous quarter. None of it worked. The bad ending stayed possible: a working product, a waiting customer and a team unable to operate it.
Deployment access is part of the product
Teams often treat deployment access as a technical detail attached to one person. In practice, it is part of the company’s ability to deliver its promise.
The deployment account controls more than a release. It may control production credentials, billing, monitoring, domains, databases, logs and the ability to reverse a bad change. When one person owns the only path through that system, their departure creates a business interruption.
The code can be clean. The documentation can be thorough. The company can still be unable to serve a customer.
This is why access reviews belong in the same conversation as roadmap reviews and runway. If the business depends on a system, someone must own the system, someone else must be able to recover it, and the company must know how that recovery works.
The real test happens when the relationship changes
Before a departure, exclusive access often feels efficient. The person who built the system knows how it works, responds quickly and keeps the credentials close. Small teams make these choices because everyone is busy and the arrangement appears harmless.
The arrangement changes when the person leaves, becomes unavailable or stops cooperating.
That moment reveals whether the company has institutional knowledge or one person’s memory. It also exposes a common mistake in founder-led teams: confusing trust with control.
Trusting a cofounder does not require giving one person permanent, unrecoverable control over a critical system. A sensible setup can preserve privacy and reduce unnecessary access while still ensuring that the company can operate during illness, conflict, resignation or a lost device.
The minimum questions are practical:
- Who owns the account?
- Where does the recovery method live?
- Can two people deploy without sharing a personal password?
- Can access be removed quickly?
- Has anyone tested the recovery path recently?
- What happens if the person who knows the answer cannot be reached?
These questions are uncomfortable because they sound like preparation for a dispute. They are really preparation for continuity.
Design the recovery path before you need it
The fix is rarely a giant process document. It is a small set of deliberate decisions made while the team is still working well together.
Use company-controlled accounts for production systems. Keep recovery methods in a location the company can access. Separate personal identity from administrative authority where the tools allow it. Record the steps required to deploy, roll back and rotate credentials. Give at least one other person enough access to perform the task, then review that access when roles change.
Run the recovery exercise as a test, not a ceremony. Ask someone who did not create the system to follow the instructions. If they need to message the original owner three times, the company has found a dependency worth fixing.
This is the same pattern behind replacing admin access with approval. Control should be explicit, reviewable and recoverable. The goal is not to give everyone access to everything. The goal is to ensure that one departure cannot quietly become a service outage.
Lina eventually found a second route into the hosting account through an older company-managed address. The team rotated the credentials, documented the deployment sequence and moved the customer fix into production that afternoon.
A month later, she repeated the exercise with the other engineer. The engineer could deploy and roll back without Lina or the former cofounder. The exercise took less time than the original password search.
The lasting change was small. On the next Thursday, the team no longer needed one person’s availability to keep the company moving.
Comments
No comments yet.