The Single-Founder Ops Stack
Running infrastructure as one person. What to monitor, what to automate, and what to document so the business survives your two-week holiday.
One-person businesses are a strange operating regime. You are the CEO, the engineer, the support lead, the ops person, and — whether you admit it or not — the on-call.
The usual advice about ops assumes a team. "Document everything." "Build a runbook culture." "Have a backup on-call." None of this is possible when there's one human. But the underlying need — that the business survives you being unavailable — is just as real, and arguably more acute.
The single-founder ops stack is a different beast. Here's what it actually looks like when done well.
What breaks a single-founder business
Before designing the stack, it helps to know what you're defending against. The two failure modes that specifically target one-person businesses:
You're unavailable when something breaks. Illness, family emergency, holiday in a place with bad internet, or just sleeping. There is no second shift. If the business requires your attention to stay up and you can't give it, the business goes down.
You forget something. No one else is tracking it. Domain renewal, SSL rotation, compliance filing, subscription renewal. You meant to do it, something else was urgent, months passed, you find out when a customer emails.
Both of these kill one-person businesses quietly and regularly. Everything in the stack below exists to mitigate one or the other.
The core stack
Four layers, each solving a specific version of the "you aren't there" problem:
1. Monitoring you don't watch
If monitoring requires you to check a dashboard, it will fail you. You'll be busy, distracted, or travelling. The monitoring has to be push-based — alerts come to you, not the other way around.
For a one-person business, the minimum is:
- Uptime monitoring on the primary site (1-minute checks) — Website Uptime Monitor
- SSL certificate expiry (weekly; alert under 30 days) — SSL Certificate Expiry
- Domain expiry (daily; alert starting 90 days out) — Domain Expiry Watcher
- DNS change detection (alert on unexpected changes) — DNS Monitoring Tool
- Email authentication (SPF/DKIM/DMARC) — if you send any email — Email Deliverability Checker
- Vendor status (subscribe to status pages for anything critical) — Is That Down
All six are live today; Site Watcher wraps the first five into one dashboard if you'd rather not run each separately.
Route all of this to one channel. Not three channels. One. If you split the signals, you'll watch one and not the others.
2. Automation with verification
Automate the recurring stuff that kills you if forgotten. But — critically — verify that the automation worked. Set-and-forget done right isn't about being lazy; it's about making the system robust enough that forgetting is safe.
Specifically:
- SSL renewal is automated. A monitor confirms the new cert is actually in use.
- Domain auto-renewal is on. A monitor confirms the expiry date is moving forward as expected.
- Backups run nightly. A monitor confirms the backup size is in the expected range.
- Payment methods at critical vendors have expiration monitoring.
The question to ask of every automated task: "If this silently fails for three months, will I notice?" If the answer is no, add verification.
3. Kill-switch readiness
The business should be able to enter a safe state without your intervention. This is rarely documented but often valuable for one-person ops:
- A "maintenance mode" page that activates if the backend is unreachable. Customers see a branded message instead of a generic error.
- An auto-responder on the primary support inbox that sets expectations if you're unavailable.
- A status page (hosted, not self-hosted) that you can update from your phone with minimal effort.
None of these replace fixing the problem. All of them buy you time and customer goodwill if you can't fix it immediately.
4. The "hit by a bus" document
One written document, updated twice a year, that a competent technical person could use to take over operations if you weren't available.
Not comprehensive. Not polished. Functional. Contents:
- Where all the services run (hosting, DNS, email, etc.)
- How to access each one (manager tool + description of where to find credentials)
- Known ongoing issues and their workarounds
- Vendor list with contact info for each
- How to put the site in maintenance mode
- How to respond to customer support basics
- Who to call for legal or financial questions
This document is uncomfortable to write. You'll want to make it too short or too long. Aim for something a technically competent person could read in an hour and use to keep the lights on for a week.
What you don't need
Single-founder ops often gets over-engineered by founders who've come from bigger companies. Some of the things you can safely skip:
On-call rotation. You're the rotation. Pretending otherwise wastes time.
Formal incident management processes. A simple note-to-self when something breaks is fine. You don't need a blameless post-mortem culture when you're the only person who could be blamed.
Elaborate runbooks. You know the system. One-line notes for unusual alerts are enough.
Team-based alerting infrastructure. PagerDuty-style rotations don't apply. A single alert destination you actually watch is better.
Compliance platforms. Until a customer asks, skip them. See the compliance vs. common-sense piece for why.
Enterprise-grade monitoring suites. Absolute overkill. The middle-path monitoring stack is correct for SMBs and especially for one-person operations.
The availability compact
Single-founder businesses benefit from being honest with customers about the operating model. Not in a defensive way — in a direct way.
"We're a small team. Response time is business hours. For emergencies, here's how to reach us." Set on the support page, in the contract if you have one, on the auto-responder.
Customers who need 24/7 support won't buy from you, which is fine — they weren't the right fit. Customers who accept the model will be more patient when something does happen, because they knew the shape of the operation going in.
This is also a hedge against alert fatigue. If every customer expects instant response, every alert feels urgent. If the operating model is explicit, genuine incidents get genuine urgency and routine questions get routine treatment.
The long-term pressure
One-person ops scales, but not forever. Over time, as the business grows, the pressure to bring in help — even part-time — increases. The signs that it's time:
- You've cancelled personal plans more than twice in a year to handle something operational
- You're missing the "hit by a bus" document update because you don't have time
- A genuine incident went unhandled for more than a few hours because you were unreachable
- You're the bottleneck on customer deals because you can't answer technical questions fast enough
None of these mean you need a full-time hire. They often mean you need a contractor on retainer who can cover basic ops in your absence. The cost is less than you'd expect, and the mental cost of carrying everything alone is higher than people admit.
The pillar on boring IT for SMBs frames this as a durability-of-operation question. Single-founder ops is a specific case: the business only works as long as one specific person does. The stack above is designed to widen the margin — make the business survive you being unavailable for a week, a month, or in worst case longer than that.
The short version
Single-founder ops is not "minimum viable corporate ops." It's a different operating regime. The stack optimises for three things: monitoring that comes to you, automation that verifies itself, and a written artifact that lets someone else run the show if you can't.
If you've got all three, your business is more durable than a lot of VC-backed companies with twelve-person engineering teams. If you're missing any of them, fix that before scaling anything else.