{"course":{"slug":"cloud-and-shipping","title":"Shipping It","url":"https://addaly.com/learn/cloud-and-shipping","level":"intermediate","track":"build"},"lesson":{"slug":"shipping-alone-sustainably","title":"Keeping it going without burning out","url":"https://addaly.com/learn/cloud-and-shipping/shipping-alone-sustainably","position":74,"of":74,"minutes":9,"answer":"Attention is the scarce resource in a small project, so decide in advance what is worth waking for, automate the frequent and write runbooks for the rare, refuse features you cannot maintain.","keyIdea":"Attention is the scarce resource in a small project, so decide in advance what is worth waking for, automate the frequent and write runbooks for the rare, refuse features you cannot maintain, and judge the system by how long it runs without you and how quickly you can understand it when you return."},"body":{"format":"markdown","text":"## The constraint nobody puts in the architecture diagram\n\nEverything 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.\n\nSo 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.\n\n## Decide what \"down\" costs before you promise anything\n\nA one-person project cannot offer 24-hour response and should not pretend to. The honest version is to decide, in advance, three tiers:\n\n- **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.\n- **Same day:** a feature is broken, a subset of users is affected, an alert that means something is degrading.\n- **This week:** everything else, including most of what currently pages people.\n\nWrite 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.\n\n## Automate the recurring, accept the rare\n\nA useful test for any piece of operational work: how often does it happen, and how long does it take?\n\n- **Frequent and short:** automate it. Dependency updates, certificate renewal, backup verification, deploys.\n- **Frequent and long:** this is where you are losing your life. Fix the underlying cause, or the automation, or the feature.\n- **Rare and short:** do it by hand, from a runbook.\n- **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.\n\nThat last quadrant is where a lot of over-engineering lives, usually justified as saving time.\n\n## Reduce the surface deliberately\n\nEvery 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.\n\nSo 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.\n\nThe 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.\n\n## Build for the version of you who is tired\n\nThe 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:\n\n- A runbook with the actual commands, copy-pasteable.\n- A rollback that is one command and needs no thought.\n- Alerts that link to the runbook.\n- A `/version` route so you know what is live.\n- A kill switch per risky feature.\n- Notes in the decisions file explaining why something strange is the way it is.\n\nNone of that is glamorous. All of it converts a bad night into twenty minutes.\n\n## Take real breaks, and design for them\n\nThe 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.\n\nIf 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.\n\n## The measure of a well-run small system\n\nNot 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.**\n\nA 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."},"check":{"question":"A solo maintainer spends four hours a month manually reconciling a data import that fails in a predictable way. Which quadrant is this, and what follows?","options":[{"text":"Rare and long: write a runbook and accept the cost","correct":false,"tempting":"Monthly and four hours is neither rare nor cheap; accepting it means surrendering nearly a working week a year to one task."},{"text":"Frequent and long: the underlying failure should be fixed, since this is where a maintainer's capacity is actually consumed","correct":true},{"text":"Frequent and short: automate the reconciliation script","correct":false,"tempting":"Automating the cleanup preserves the fault and hides it; the work is long precisely because the import keeps failing."},{"text":"Rare and short: no action needed beyond documentation","correct":false,"tempting":"Misjudges both axes, and documenting a recurring multi-hour task simply makes the loss repeatable by somebody else."}]},"prev":{"slug":"the-paperwork-of-a-public-site","title":"The pages every public site needs","url":"https://addaly.com/learn/cloud-and-shipping/the-paperwork-of-a-public-site"},"next":null,"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Keeping it going without burning out', in Shipping It. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/cloud-and-shipping/shipping-alone-sustainably (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Keeping it going without burning out","courseTitle":"Shipping It","module":{"index":8,"slug":"running-it-for-years","title":"Running it for years"},"answer":null,"keyIdea":"Attention is the scarce resource in a small project, so decide in advance what is worth waking for, automate the frequent and write runbooks for the rare, refuse features you cannot maintain, and judge the system by how long it runs without you and how quickly you can understand it when you return.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-constraint-nobody-puts-in-the-architecture-diagram","runs":[{"text":"The constraint nobody puts in the architecture diagram"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"decide-what-down-costs-before-you-promise-anything","runs":[{"text":"Decide what “down” costs before you promise anything"}]},{"t":"p","runs":[{"text":"A one-person project cannot offer 24-hour response and should not pretend to. The honest version is to decide, in advance, three tiers:"}]},{"t":"ul","items":[[{"text":"Wake me:","b":true},{"text":" 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."}],[{"text":"Same day:","b":true},{"text":" a feature is broken, a subset of users is affected, an alert that means something is degrading."}],[{"text":"This week:","b":true},{"text":" everything else, including most of what currently pages people."}]]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"automate-the-recurring-accept-the-rare","runs":[{"text":"Automate the recurring, accept the rare"}]},{"t":"p","runs":[{"text":"A useful test for any piece of operational work: how often does it happen, and how long does it take?"}]},{"t":"ul","items":[[{"text":"Frequent and short:","b":true},{"text":" automate it. Dependency updates, certificate renewal, backup verification, deploys."}],[{"text":"Frequent and long:","b":true},{"text":" this is where you are losing your life. Fix the underlying cause, or the automation, or the feature."}],[{"text":"Rare and short:","b":true},{"text":" do it by hand, from a runbook."}],[{"text":"Rare and long:","b":true},{"text":" 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."}]]},{"t":"p","runs":[{"text":"That last quadrant is where a lot of over-engineering lives, usually justified as saving time."}]},{"t":"h2","id":"reduce-the-surface-deliberately","runs":[{"text":"Reduce the surface deliberately"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"build-for-the-version-of-you-who-is-tired","runs":[{"text":"Build for the version of you who is tired"}]},{"t":"p","runs":[{"text":"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:"}]},{"t":"ul","items":[[{"text":"A runbook with the actual commands, copy-pasteable."}],[{"text":"A rollback that is one command and needs no thought."}],[{"text":"Alerts that link to the runbook."}],[{"text":"A "},{"text":"/version","code":true},{"text":" route so you know what is live."}],[{"text":"A kill switch per risky feature."}],[{"text":"Notes in the decisions file explaining why something strange is the way it is."}]]},{"t":"p","runs":[{"text":"None of that is glamorous. All of it converts a bad night into twenty minutes."}]},{"t":"h2","id":"take-real-breaks-and-design-for-them","runs":[{"text":"Take real breaks, and design for them"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-measure-of-a-well-run-small-system","runs":[{"text":"The measure of a well-run small system"}]},{"t":"p","runs":[{"text":"Not uptime. Not the number of features. It is this: "},{"text":"how long can it run without you, and how quickly can you understand it when you come back.","b":true}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"A solo maintainer spends four hours a month manually reconciling a data import that fails in a predictable way. Which quadrant is this, and what follows?"}],"options":[{"text":[{"text":"Rare and long: write a runbook and accept the cost"}],"correct":false,"tempting":[{"text":"Monthly and four hours is neither rare nor cheap; accepting it means surrendering nearly a working week a year to one task."}]},{"text":[{"text":"Frequent and long: the underlying failure should be fixed, since this is where a maintainer’s capacity is actually consumed"}],"correct":true,"tempting":null},{"text":[{"text":"Frequent and short: automate the reconciliation script"}],"correct":false,"tempting":[{"text":"Automating the cleanup preserves the fault and hides it; the work is long precisely because the import keeps failing."}]},{"text":[{"text":"Rare and short: no action needed beyond documentation"}],"correct":false,"tempting":[{"text":"Misjudges both axes, and documenting a recurring multi-hour task simply makes the loss repeatable by somebody else."}]}],"order":[2,1,3,0],"why":null},"prev":{"slug":"the-paperwork-of-a-public-site","title":"The pages every public site needs","minutes":9},"next":null}}