A side project begins as a weekend of building and becomes a subscription of small obligations: dependency updates, expired certificates, a domain renewal, a flaky test, an issue from a stranger. None of these is large. Together they explain why so many projects are technically alive and practically abandoned.

The fix is not to avoid dependencies or to work more. It is to treat maintenance as a budget with a number, and to make the number visible before the project starts asking for more.

Count the monthly payments

List everything that will demand attention after launch:

  • Runtime and framework updates. Security patches arrive whether or not you have time.
  • Third-party services. Auth, email, storage, payments — each has a dashboard, a key rotation, and a pricing page that changes.
  • Hosting and databases. Backups, disk space, logs, and the one config that only exists in the dashboard.
  • Content and data. A feed that stops updating, a scraper that breaks, a model that gets deprecated.
  • People. Issues, pull requests, and support email from users who expect an answer.

Not all of these apply to every project. The exercise is to name the ones that do, and to estimate the recurring attention each one needs. A static site with no backend may cost an hour a year. A full-stack app with auth, email, and a cron job can cost an hour a week, which is fifty hours a year — a number most people never write down.

Set a budget you can actually keep

Pick a maintenance budget in hours per month and write it next to the project's README. Two hours is a common and realistic number for a small app. One hour is enough for a static site. Zero is a legitimate choice, but only if the project is archived and the domain is allowed to lapse.

The budget is a ceiling, not a target. When the month's maintenance exceeds it, something has to change: remove a dependency, drop a feature, or end the project. The alternative is to quietly borrow the time from something else, which is how a side project turns into guilt.

Design for a smaller bill

Maintenance cost is mostly decided at design time, long before the first update.

Prefer boring infrastructure. A managed database and a single deploy target are cheaper to maintain than a cluster you assembled yourself. The interesting choice is usually the expensive one.

Every dependency must justify itself. A library that saves an hour today can cost an hour every quarter in upgrades and breaking changes. If the code you would write is under a hundred lines and stable, write it.

Separate the data from the app. Backups in a format you can read without the app are the difference between a broken deployment and a lost project. Test a restore once; an untested backup is a hope.

Put every secret in one place and rotate on a schedule. A key that lives in three dashboards and one chat message is a future incident. Rotation is a calendar entry, not a memory exercise.

Make the build reproducible. A project that installs from a lockfile and deploys with one command is cheaper to resume after six months of neglect. The command matters more than the pipeline.

The kill criteria

A side project should have a written condition under which it ends. Without one, the default is indefinite low-grade maintenance, which is the worst outcome for attention.

Useful kill criteria:

  • No meaningful use for six months.
  • Maintenance regularly exceeds the monthly budget for two consecutive months.
  • A dependency has a security issue you cannot fix within a week.
  • The project's purpose is now served by something you already pay for.
  • You no longer want to be the person who answers its issues.

None of these is a failure. A project that ends cleanly has delivered its value and stopped asking for more. Archive the repository, write a short note explaining what you learned, and either keep the domain or let it go. An honest ending is cheaper than a slow fade.

The resume test

If you stop for six months, can you resume in one afternoon? Check three things: does the lockfile install on a current runtime, does the deploy command still work, and is the data restorable? If any answer is no, the project's real maintenance cost is higher than the budget suggests, and it is worth fixing now rather than at the moment you want to work on it.

This test is also a good filter for new projects. Before you start, ask whether you would be comfortable resuming it after a long pause. If the answer is no, the architecture is too heavy for a side project, no matter how interesting the idea.

Write the budget down

The single most effective step is visibility. Put three lines at the top of the README:

  • Maintenance budget: two hours per month.
  • Current cost: what actually happened last month.
  • Kill criteria: the conditions under which this ends.

A project with a visible budget is easier to keep, easier to pause, and easier to end. A side project is supposed to add something to your life. The budget is how you make sure it does not quietly take more than it gives.