A Capacity-First System for Shipping Side Projects

The side-project plan usually looks sensible on Sunday.

Then Monday takes more out of you than expected. Tuesday’s “quick task” opens three dependencies. Wednesday disappears. By Thursday, the project has not merely fallen behind; it has become mentally expensive to reopen.

Most productivity advice treats this as a discipline problem.

I think it is a product-design problem.

A side-project release has to be designed around the week that repeatedly exists, not the week you occasionally survive.

Start with capacity, not ambition

Write down the focused hours you can protect during an ordinary week. Remove the fantasy sessions: the five-hour evening after a full workday, the uninterrupted Saturday, the lunch break that never gets interrupted.

Suppose the honest number is four hours.

A release estimated at twenty hours is not “challenging but possible.” It is five weeks of work before interruptions, re-entry cost, defects, and decisions. If you are planning to ship it next Friday, one of three things must change:

• the scope,
• the date,
• or the available capacity.

Motivation is not a fourth variable.

Turn the ambition into a release slice

“Launch the app” is not a useful unit of work. Neither is “finish the course” or “publish the book.” Each phrase hides too many independent decisions.

A release slice has four parts:

1. One user or reader. Who receives this version?
2. One job. What can they do when it is finished?
3. One inspectable artifact. What file, page, or behavior proves it exists?
4. One completion test. How will you know this slice stops?

For a software product, the slice might be: a new user can create one project, receive one useful result, and understand the current limitation from the empty state.

For a digital guide, it might be: the buyer can open the guide, download the working files, and complete the first workflow without a missing dependency.

The smaller statement is not less ambitious. It is the part of the ambition that can become real next.

Create a Not Doing List

A backlog preserves ideas. It does not protect the current release.

The Not Doing List names attractive work that is explicitly excluded:

The final column matters. A scope cut should feel reversible, not dishonest. You are not declaring the idea bad. You are refusing to make it a dependency of today’s release.

Leave a restart packet after every session

Fragmented work is expensive because every session begins with reconstruction.

You reopen the repository. You inspect half-finished files. You remember why an apparently obvious option was rejected. Twenty minutes disappear before the next meaningful action becomes clear.

The fix is a tiny restart packet:

• current release name,
• exact file or screen being changed,
• decision already made,
• current defect or uncertainty,
• next physical action,
• completion test for that action.

“Continue onboarding” transfers no state.

“Open src/routes/onboarding/+page.svelte; replace the placeholder success state with the approved three-step version; stop when a new user can reach the dashboard without a dead end” does.

The end of one session is the interface for the next.

Use session types that match your energy

Not every task needs your best creative hour.

I separate work into three rough modes:

• Decision work: scope, architecture, positioning, or a difficult edit.
• Production work: implementing a decided change, writing a bounded section, generating a known asset.
• Closure work: tests, link checks, packaging, documentation, and the restart packet.

Trying to make a high-risk product decision at the end of a draining day often creates work that must be reversed. Closure work may be the better use of that evening.

This is not about assigning a personality type to every hour. It is about avoiding the assumption that all remaining tasks are interchangeable.

Review evidence, not effort

At the end of the week, do not ask whether you worked hard enough. Ask what changed in the project.

Record:

• artifacts completed,
• estimates that were wrong,
• dependencies that repeatedly blocked entry,
• scope added after the boundary was set,
• defects that escaped the completion test,
• and the first action for the next week.

Then change the system.

If re-entry consumed the sessions, improve the restart packet. If one item consumed most of the week, split the slice. If decisions kept appearing during production, move them into a dedicated decision session.

A review earns its place only when the next week becomes easier to enter.

Estimate before the task becomes emotionally protected

Rough estimates are useful even when they are wrong.

Estimate the release parts before defending them. Compare the largest item with the week’s recurring capacity. If one feature consumes most of the available time, ask whether it produces most of the release’s value or merely carries the most attachment.

Update the estimate after each session. A task estimated at ninety minutes that has consumed four hours is new evidence. Either the task is misunderstood, the completion test is too broad, or the implementation has revealed a dependency.

The purpose is not accurate forecasting. It is early visibility into hidden cost.

Keep a release record, not a launch fantasy

At the end of the week, preserve one small record:

• current release and version,
• completed evidence,
• open defects,
• changed assumptions,
• latest Not Doing List,
• current estimate,
• next action.

This is an internal handoff, not a social announcement. It should not invent a public launch, sales, customer feedback, or momentum that did not occur.

If the date moved, record why. If a feature left scope, preserve the decision. If nothing shipped publicly, state the artifact that did become more complete.

Use public commitments carefully

A public date can clarify priorities, but it cannot create missing capacity.

Commit to an artifact you control: a draft published for review, a beta opened to a defined group, a video uploaded, or a release candidate packaged. Avoid commitments whose success depends on sales, rankings, approval, or other people’s behavior.

The public statement should make the boundary sharper. If it merely adds pressure while the release remains vague, it is another dependency.

Measure recoverability

Streaks are fragile. A useful system expects interruption.

The better measurement is: how quickly can the project return to meaningful work after a gap?

A recoverable project has a stable release boundary, a current record, a small next action, and source files that explain the latest state. It does not depend on remembering the emotional momentum of last Tuesday.

This matters more than a perfect calendar. Full-time work, relationships, health, and ordinary life will eventually break the streak. The system should survive without turning the interruption into a verdict on the project.

Where AI helps and where it does not

AI can summarize a release record, draft bounded copy, compare files, generate variants, or run repeatable checks. It is useful after the task has an input, an expected artifact, and a review standard.

It cannot rescue an undefined release. Giving an agent a twenty-hour scope and a four-hour week may produce more output, but it does not remove the decisions, review, and correction work.

Automate repetition after scope. Do not use generation volume to hide an impossible slice.

A one-page capacity contract

Keep the contract near the work rather than inside a planning archive. Review it before accepting a new dependency, not only when the week has already failed.

The contract should change when the evidence changes. If the recurring capacity improves, the release can grow deliberately. If the project reveals a larger defect, the release may need to shrink again. Neither move is a moral judgment.

The useful comparison is between capacity and the current slice. A smaller slice completed and reviewed produces information. An oversized slice preserved for another month produces mostly uncertainty.

Before the next side-project week, write this on one page:

• Recurring focused capacity: ___ hours
• Current release: ___
• User job: ___
• Completion artifact: ___
• Completion test: ___
• Not Doing this release: ___
• Next physical action: ___
• Weekly review time: ___

If the release does not fit the capacity, cut it before defending it.

The free Indie Creator Toolkit Roadmap begins with this capacity diagnosis. Use it before buying another productivity system.

If the diagnosis shows that the recurring week, not a missing specialist workflow, is the real constraint, the Ship After 5 Toolkit contains the full worksheets and operating system.

The goal is modest: make the next useful release small enough to exist, and make the project easy enough to reopen that an imperfect week cannot erase it.

That modesty is not a retreat from serious work. It is how serious work survives a life that already contains obligations. A capacity-first system converts ambition into a sequence of releases that can be completed, inspected, and improved instead of one heroic plan that must be restarted from memory.