What it costs to keep alive

The hosting bill is the smallest number on this page, and it is also the number most people write down when someone asks what a project costs to keep alive. A finished sports-guides site with no traffic might run $8 a month to host. That is not the number. The number is everything else — support replies, a dependency that broke overnight, a platform that changed the rules while you were not looking — and almost nobody has actually measured it for their own projects.

What “maintenance load” actually means

Define it precisely or it stays a feeling: maintenance load is the hours per month, plus the dollars per month, it takes to keep a product exactly as good as it already is — at zero growth. No new features, no marketing push, no chasing the next customer. Just what it costs to stop the thing from breaking or going quiet. That is the definition the glossary pins the term to, and every lesson after this one means exactly that by it.

That definition is not invented for this course. It is the Site Reliability Engineering book’s definition of toil, borrowed because it is more precise than anything a solo builder tends to reach for on their own. The book’s own sentence:

“Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” (Google, Eliminating Toil)

Six criteria, not five, and each one earns its place:

• Manual — doing the thing by hand, even if the thing is running a script.
• Repetitive — work you do over and over, not once.
• Automatable — a machine could do it as well as you can.
• Tactical — interrupt-driven and reactive, not something you scheduled.
• Devoid of enduring value — the service is in the same state after you finish as before you started.
• O(n) with service growth — the work scales up linearly with size, traffic, or users.

Of the six, tactical is the one worth remembering hardest for a solo project. A support email and a broken payment webhook arrive on the world’s schedule, not yours. At Google, toil above a threshold gets escalated to a roster of people who share it and can push back when it exceeds half their time. On your shelf, there is no roster. Whatever toil a project generates, you absorb all of it, and the SRE book was never written with that constraint in mind — which is exactly why it is worth reading past the definition, not just borrowing the sentence.

The categories nobody counts

Ask someone to estimate a project’s upkeep and they will name the hosting bill and stop. Here is what the hosting bill leaves out.

Support

The password reset nobody could complete, the “how do I …” email, the confused message about a checkout step that seemed obvious when you built it. Individually trivial, collectively the most tactical item on this list — it is toil in the book’s exact sense: manual, repetitive, and the product is no better for having answered it.

Dependency breakage

A payment library ships a breaking change. A build starts failing on an upstream update you didn’t ask for. None of this is optional and none of it was scheduled by you — it is automatable in principle and tactical in practice, which is the combination that makes it easy to forget when you are sizing a project from a spreadsheet instead of from experience.

Platform review cycles

If a project ships through an app store, two vendors set the terms and both are worth naming as exactly that — companies describing the rules that govern their own platforms, not neutral infrastructure.

Apple charges rent: $99 a year, recurring, for the Apple Developer Program, published on Apple’s own enrollment page. Google charges a door fee: $25 once to open a developer account, per Google’s own support page — and never again. That asymmetry belongs in the number: one platform bills you every year you stay listed, the other bills you once to walk in the door.

Apple also publishes its own review-speed claim — “90% of submissions reviewed in less than 24 hours”, self-reported with no published methodology, and noticeably faster than the 48-hour figure that still circulates in older forum threads. Take it as Apple’s own claim about Apple’s own process, not an observed guarantee for your submission specifically.

The recurring tax that actually bites every shipping developer, including one fixing a single typo, is Apple’s SDK minimum: apps must be built with the current year’s Xcode and SDK — Xcode 26 / iOS 26, in force since April 28, 2026, per Apple’s own upcoming-requirements page. The same page shows the identical rule a year earlier, with the prior Xcode version — this is an annual spring event, not a one-off. It matters more than the app-removal policy below, because it fires the moment you want to ship anything at all, not only when you have gone silent.

Google Play’s equivalent pressure is a target-API deadline, not a removal policy: new and updated apps must target API level 36 by August 31, 2026, existing apps must hold at least API level 35, and an extension to November 1, 2026 is available on request. Missing the deadline does not delist an app — it stays installed and available on older Android versions, and simply stops being offered to new users on newer ones. Delisting-by-degrees, not deletion, but it still costs an update you have to make on Google’s calendar, not yours.

Content going stale

A half-built recipe app for kids ships a nutrition guideline that is current the day it launches and quietly wrong two years later. Nobody flags it until a parent emails, and by then it has been wrong for a while. Content does not maintain itself just because the code around it never changes.

The tax and compliance tail

VAT thresholds, a business-license renewal, a filing with a date attached — this is overhead in the SRE book’s own vocabulary, not toil, but it still lands on the same person with the same finite evenings. This course names it as a category worth budgeting; it does not tell you how to file it — that is real tax and legal advice, and belongs with someone qualified to give it.

Why the first estimate is always low

Two things conspire against a first-pass number. First, people size maintenance from the categories that are visible on a bill — hosting, a subscription, maybe an app-store fee — and the categories above are visible only in hindsight, one support email or one broken build at a time. Second, the defining trait of toil is that it is tactical: it does not announce itself in advance for you to schedule around, so an estimate made at a desk, in a calm hour, structurally cannot see it coming. You are not bad at estimating. You are estimating a category of work whose entire nature is to arrive uninvited.

Measuring rather than guessing

The fix is not a better guess. It is a log, kept for long enough that the tactical items actually show up in it.

What this does not cover

A measured maintenance number and a competitor charging money for something similar are now both sitting on the table for this project. Neither one is a decision by itself. Turning those facts into a written verdict — pursue, park, or kill, with a dated revisit — is what comes next.