One person knows how to deploy it

One person knows how to deploy it means you do not have a release process. You have a person. When they are on holiday, in a meeting, or leaving the company, shipping and recovering production waits on their phone. UK SaaS and product teams hit this quietly until a Friday outage makes it expensive.

Why this is a business problem

A single deployer is not “tech debt” you can ignore until the next funding round. It is operational risk. Releases stall because nobody else will touch production. Incidents drag because the runbook lives in one head. Holidays become freezes. Hiring slows because the next engineer cannot prove they can ship without shadowing for months. Investors and enterprise buyers notice when change windows depend on one name in Slack.

I’ve walked into teams where every deploy was a private ritual: laptop secrets, a half-remembered script, and “don’t touch staging, it isn’t real.” That works until it does not. The cost shows up as missed launches, overtime, and a founder who cannot take a week off without staging a war room. Customers do not care that the only person who can ship is on a flight. They care that the fix did not land, and that nobody else could land it either.

Plain signs you’re there

Slack messages that start with “can you push it?” Production credentials only on one machine. Staging that nobody trusts. No written path from merge to live. Friday freezes because the deployer is out. A rollback that means ringing the same person at midnight. If your mental model of release is a name, not a step list the team can follow, you are already there.

Another tell: the pipeline exists on paper but nobody else has ever pressed it end to end. Or deploys still happen from a laptop because “CI is flaky.” That is still one-person knowledge dressed up as automation.

What good looks like for a buyer

Good is boring. A repeatable deploy the next engineer can run without a call. Shared access on accounts the company owns, not a personal cloud login. Secrets in a proper store, not a notes app. Docs beside the code: how to ship, how to roll back, who to page. Infra and pipeline in git so the path is visible. You do not need a YAML lecture. You need to know someone else can ship on Tuesday when the original deployer is offline.

Eight Mile’s infrastructure and cloud work is built for inherited scary deploys: pipelines, infra in git, and a path the team can run. Soft path when the product itself needs stabilising on accounts you own: SaaS. We walk into the mess, leave something the next person can operate, and you keep the accounts.

Rescue vs deeper rebuild

A short rescue or audit is enough when the app is sound but knowledge and access are trapped: document the path, move secrets and logins onto company accounts, put a boring pipeline in place, and pair until a second person has shipped for real. Deeper rebuild is for when the deploy path is also lying to you — snowflake servers, no staging, or changes that cannot be reproduced. Do not buy a six-month platform rewrite to fix a bus-factor problem that a focused takeover would clear in weeks.

Stop betting the product on one phone

If one person knows how to deploy it, fix the ownership and the path before the next holiday or resignation makes the risk visible to customers.

If you want a deploy the team can run on accounts you own, contact Eight Mile and say who ships today and what happens when they are away.