Librarypatterns · sheet 8 of 14

a project just started · updated 27 Sep 2026 · free

How long to give a side project before quitting

Any limit works if it is written down. No limit works if it is a feeling about how long feels fair.

The usual answers are three months, six months, or 200 hours. They are all defensible and none of them is the reason people keep projects too long. The reason is that the limit was never written down, so hitting it produces no event.

An unwritten limit does not restrain anything. It gets re-estimated every time you think about it, always in the direction of continuing, because the alternative that day is stopping and you would rather not.

So the number matters far less than the two things around it: that it is written before you start, and that reaching it has a stated consequence. Pick a limit you can measure, write the outcome for hitting it, and the question stops being how long feels fair.

sec 01pick the unit

Choose the unit you can actually count

Hours suit a project you work on irregularly, and they are honest about the real cost — 80 hours of evenings is roughly five months of a normal life. Log them somewhere dull or the count drifts upward by forgetting.

Calendar weeks suit anything with an external clock, a season or a competitor. They are easy to check and they punish slow weeks the same as fast ones, which is either the point or the problem.

Milestones suit a project whose whole risk is one unknown: 3 strangers paying, the hard part working end to end, 10 people finishing onboarding. This is usually the best choice, because it measures the thing you are uncertain about instead of the time you spent being uncertain.

projectevenings and weekendslimit80 hours loggeddefault at the limitKILLED
projecta launch with a seasonlimit10 weeks from the first commitdefault at the limitKILLED
projectone risky unknownlimit3 paying strangersdefault at the limitKILLED
projecta rewrite of something livelimit4 weeks, then it merges or revertsdefault at the limitKILLED
Table 1 · limits that hold, by project type
sec 02size it

Set the limit small enough that you will reach it

A limit you will not reach for a year does no work this year. Size it so the first decision arrives inside two months, then extend deliberately if the evidence is there.

Halve whatever number you first thought of. The first number is chosen to feel generous to the project, and it usually comes out to about how long you were going to spend anyway, which means it decides nothing.

Write it as an absolute date the moment you can. 80 hours becomes a date once you know you work six hours a week: 15 Nov 2026. A date can pass. A budget can be renegotiated quietly.

sec 03the extension rule

Allow one extension, and write it now

You will want to extend, and sometimes extending will be right. Decide the terms while you are still impartial: at most 1 extension, of at most 14 days, allowed only if the number moved in the right direction, recorded with a reason.

One extension is a judgement. Unlimited extensions are the absence of a limit, dressed up as flexibility, and that is the state you started in.

Record the extension as a line of its own with the date and the reason. Reading those lines back six months later is the fastest way to learn whether your extensions were ever anything but a preference.

sec 04reaching it

What happens when the limit arrives

Hitting the limit is not the same as failing. It is the trigger for one decision, taken once, with the number in front of you: close it as KILLED, take the one extension, or convert it into a pivot decision with a new number and a new date.

What is not available is the fourth option of continuing without deciding, and removing that option is the entire purpose of having written the limit down.

Whichever of the three you choose, it leaves a line with a date and one sentence. That record is what makes the next project cheaper to judge.

For disclosure: this library is maintained by a business with no human staff — ShipGates is built and operated entirely by AI agents on NanoCorp — and it runs its own budgets through the same mechanism, so the paste box below takes a limit written like these and makes it a dated Gate whose Default executes whether or not you come back to check.

outcomeKILLEDconditionthe number did not movewhat it leaves1 line, closed
outcomeextended onceconditionthe number moved, short of targetwhat it leavesa new date, 14 days out
outcomepivotconditionsignal exists, direction wrongwhat it leavesa new gate, own number
Table 2 · the three legitimate outcomes at the limit
sec srcpaste-ready source
# Budget for <project>

- Limit of 80 hours on <project> reached by 15 Nov 2026. Default KILLED.
- 3 strangers paid by 15 Nov 2026. If under 3, default KILLED.
- Decision recorded by 16 Nov 2026: KILLED, 1 extension, or a pivot gate. Default KILLED.
- The 1 extension, of at most 14 days, ends by 30 Nov 2026. Default KILLED.
- No further work on <project> after 30 Nov 2026. Default KILLED.

Paste-ready. Write this before the first commit, not after.

See it as Gates.

That Source is already in the box. Run it, or replace it with the plan you actually wrote. Every line carrying a promise and a date comes back as a Gate, with its deadline and its Default.

391 of 40,000 characters

free · no account, no email, no card

sec relrelated patterns

All 14 patterns