Keeping it going without burning out

The constraint nobody puts in the architecture diagram

Everything in this course assumes somebody will do it. On a small project that somebody is one or two people who also write the features, answer the emails and have a life. Attention, not money or compute, is the scarce resource, and a system that consumes more of it than you have will decay regardless of how well it was built.

So the last lesson is about designing the operation around a real person’s capacity, which is a legitimate engineering constraint and not a personal failing.

Decide what “down” costs before you promise anything

A one-person project cannot offer 24-hour response and should not pretend to. The honest version is to decide, in advance, three tiers:

• Wake me: the site is down for everybody, data is at risk, money is being lost, or a security incident is live. This should be a very short list, and every item should have a runbook.
• Same day: a feature is broken, a subset of users is affected, an alert that means something is degrading.
• This week: everything else, including most of what currently pages people.

Write it in the runbook, configure the alerts to match, and publish your actual support hours. A stated 24-hour response time that you meet is worth more than an implied instant one that you do not.

Automate the recurring, accept the rare

A useful test for any piece of operational work: how often does it happen, and how long does it take?

• Frequent and short: automate it. Dependency updates, certificate renewal, backup verification, deploys.
• Frequent and long: this is where you are losing your life. Fix the underlying cause, or the automation, or the feature.
• Rare and short: do it by hand, from a runbook.
• Rare and long: write the runbook and accept it. Building automation for something that happens once a year takes longer than the task and will be broken by the time you need it.

That last quadrant is where a lot of over-engineering lives, usually justified as saving time.

Reduce the surface deliberately

Every feature, integration, dependency and environment is a standing claim on your attention. The maintenance calendar’s length is a direct function of how many things exist.

So saying no is an operational decision, not a personality trait. Fewer features, fewer services, one language where possible, one database, boring dependencies with many users and slow release cycles, and managed services for anything stateful. Each of those choices buys back hours per month, and the previous lessons in this module are all versions of the same idea.

The strongest version: if you cannot maintain it, you cannot ship it. A feature that will need weekly attention forever is not free because the code is written.

Build for the version of you who is tired

The person who fixes the outage is you at 2am, on a phone, on holiday, six months after you last touched this code. Everything that helps them is worth more than it looks:

• A runbook with the actual commands, copy-pasteable.
• A rollback that is one command and needs no thought.
• Alerts that link to the runbook.
• A /version route so you know what is live.
• A kill switch per risky feature.
• Notes in the decisions file explaining why something strange is the way it is.

None of that is glamorous. All of it converts a bad night into twenty minutes.

Take real breaks, and design for them

The things that make time off possible are specific and buildable: a system that survives a week unattended, spend caps so a runaway cannot become an unpayable bill, an auto-reply with realistic expectations, and one other person who has access and knows where the runbook is, even if their only job is to turn the site off if it starts doing harm.

If nobody else can act, write down the one command that stops everything and make sure a trusted person has it. That is not a governance nicety; it is what stands between a bug and a week of damage while you are unreachable.

The measure of a well-run small system

Not uptime. Not the number of features. It is this: how long can it run without you, and how quickly can you understand it when you come back.

A system that runs itself for a fortnight, tells you the truth when something is wrong, and can be understood from four short documents is a well-engineered one, whatever it is built on. That is what everything in this course has been for; and it is what you can now build, deploy, watch, defend and hand over.