Pick It Up After Three Months: A Continuity Handbook for Solo Projects

The example product and person below are fictional: the example product is "PickUp Journal", a solo-built journaling tool, and the example developer is Shen Yizhou. The "continuity handbook" in this guide is written for your future self. It is not a client handover document, and it is not a context pack for an AI — the differences are explained in the text and in the boundary note.

The most common way a solo project dies is not that it cannot be built, but that once it is put down, it can never be picked up again. That is how Shen Yizhou's "PickUp Journal" died the first time: he had built about half of it the previous autumn, got busy at work, and stopped for four months. When he tried to pick it up again in winter, opening the repository felt like walking into someone else's house — he had forgotten the commands to run it, why the database was split into two tables, and why he had not used a popular off-the-shelf library. He spent a whole weekend digging through commit history, chat logs, and half-finished notes, and still did not dare touch the core code, afraid of breaking the parts that worked. So the project stopped for another three months. The second time he got smarter: instead of writing more perfect code before stopping, he left a continuity handbook for himself three months later while he still remembered. It was only a few pages, but with it he had the project running in one afternoon, and changed his first line of code the next day.

Pausing is normal, not failure. A solo project has no team to catch you, no colleague to tell you why a feature was written that way, and after enough time even the author becomes a stranger to it. So the handbook does not solve "how to write documentation". It solves "how can my future self become this project's owner again in the shortest possible time". It has exactly one reader — you, a few months later, having forgotten most of the details — and exactly one acceptance test: can you follow it to get the project running within a day, make a first change, and know which pitfalls not to step on? A handbook that fails that test is useless no matter how pretty it is.

The handbook is not those other documents

First, separate the continuity handbook from several documents it is easily confused with, so you do not write the wrong thing. Developer documentation is written for other people: how to call an API, how to use a feature. Its readers are users and future maintainers. A continuity handbook is written for your future self: how you were thinking, and where to start. Writing the README before you start coding helps you think through what to build — that is a starting document. A continuity handbook is left when you stop midway: how far you got, what remains, what to do first when you return. A user help center is a self-service knowledge base for end users, about how a feature is used. A continuity handbook is about why a piece of code looks the way it does. Different readers entirely.

Two more are easily confused. A client handover document is about letting the client's side operate independently, with billing and responsibilities — it carries business and accountability content. A context pack for an AI is about giving an AI enough context within one conversation, formatted for machine reading. A continuity handbook is neither: it does not aim for completeness, formality, or good looks. It aims for "my forgetful future self can restart fastest". So it can be colloquial, it can say "do not touch this, I forgot why but the tests fail if you do" — undignified sentences are fine, as long as future you understands them and dares to act. Writing it to look like a public document is counterproductive: fear of writing it badly becomes the reason nothing gets left behind at all.

The five parts of a continuity handbook

A continuity handbook does not need to be long. Five parts are enough. First, one page of current status, in the plainest words: does it run, where does it run, which parts are half-built, which parts have known bugs not yet fixed. Shen Yizhou's status page was six lines: the web version runs, the mobile version is only a shell, export is half-built and loses formatting, login uses a test account system not yet replaced with a real one, images are stored locally and not yet on the cloud, and payments have not started at all. Six lines, and future him immediately knew how far the project was from usable, without guessing from code.

Second, a thirty-minute startup checklist: every step from zero to running, in order, with no steps skipped. What to install, what commands to run, which environment variables are needed, how to initialize the database, and which address to open to see what. Crucially, every step must state what success looks like — for example, "after this command, the last line in the terminal should read Listening on 3000, and opening localhost:3000 should show the login page". Without a success criterion, when you get stuck on a step you cannot tell whether you made a mistake or the environment did. Shen Yizhou added one more rule: if a step is likely to fail on a new machine, write down what the failure looks like and how to work around it. That one rule later saved him a whole evening.

Third, a decision log: only the decisions someone else would have made differently, three sentences each — what was chosen, why, and what was given up. Not every decision deserves an entry, only the ones you would regret revisiting: why the database was split into two tables, why a popular library was not used, why an interface was deliberately written in a roundabout way. The decision log pays off most at restart time: you see an awkward piece of code, your first instinct is "who wrote this stupid code, let me fix it", and the log shows it was bent that way because of a third-party limitation — fixing it would walk straight back into the same trap. Shen Yizhou's log had only nine entries, but each one stopped a well-meaning refactor that would have caused harm.

Fourth, a map of known pitfalls: listed problems, how to reproduce them, and temporary workarounds. Do not wait until they are fixed to write them — it is precisely the unfixed ones that must be written down: which feature crashes under what conditions, which export mangles formatting, which account is for testing and must not be used for real payments. Date each entry, because some pitfalls may have been fixed along the way, and the date lets future you judge whether an entry still applies. Fifth is "handover to yourself": where accounts, services, keys, domains, and deployment locations live. Note carefully: this section records only where things are kept and which password manager holds them — never write passwords or secret keys in plain text into the handbook. The handbook goes into the repository, gets synced and backed up; plain-text secrets in it are a trap for your future self.

Write it the way a forgetful person needs it

The writing rules for a continuity handbook differ from ordinary documentation. Rule one: assume the reader remembers nothing. Do not write "run it the usual way" — write the exact command. Do not write "configuration as before" — write where the config file is and which items must change. Do not write "you know what I mean" — future you is precisely the person who does not. Shen Yizhou's test: after writing, wait three days, pretend to be a newcomer, and see whether the handbook alone gets the project running without skipping a step. Anywhere you need to "think for a moment" is somewhere the handbook is not written well enough.

Rule two: every entry carries a date and a "why". The date helps future you judge freshness; the "why" helps judge whether the decision still holds. For example: "August 2026: images stored locally for now because the image service's free quota was nearly exhausted; move to the cloud once users pass one hundred." That sentence has a time, a reason, and a trigger — on return you can immediately tell whether it is time to change. A handbook of conclusions without reasons is as good as unwritten at restart time, because you cannot tell whether the conditions behind a conclusion have changed. Rule three: record only what cannot be derived. What is obvious from the code does not need copying into the handbook; what is not visible in code — why it was written that way, what failed when tried, which service is about to expire — is what deserves writing. The shorter the handbook, the more likely it is maintained; the longer it is, the more likely it is already out of date before the next pause.

One more practical rule: put the handbook where future you will definitely see it. Tucked in a corner of some cloud notebook, it is worse than useless; sitting in the repository root under an obvious name, it is found immediately. Shen Yizhou put his in the repository root, named RETURN.md, with the first line reading "if you are back after a long break, start here". Placement matters more than polish, because on restart day what you lack most is not information, but patience to hunt for it.

AI-collaboration pauses are harder to resume than human ones

Many solo projects today are built with AI, and resuming after a pause adds another layer of difficulty: you have forgotten not only how you thought, but also how the AI was taught. Conversation logs with an AI run to tens of thousands of words; reading them all is unrealistic, and the real decisions are scattered among trial and error. The handbook needs a separate short section for AI collaboration: what key constraints were given to the AI, what unwritten rules the project has, and what the AI must never change. For example: "database changes must be asked about first", "do not restructure three files to fix one bug", "this function is hand-written, do not let the AI rewrite it". These constraints were the tacit understanding worked out between you and the AI; rebuilding it after a pause costs no less than re-understanding the code.

AI-generated code has another trait: it all looks plausible, but some parts were let through without close review at the time. The handbook should honestly mark "these parts were AI-generated and I did not review them closely", so that on return you review those first instead of assuming they are correct. Shen Yizhou's handbook had a section called "not closely reviewed", listing three items: the export format conversion, image compression parameters, and login edge cases. In his first week back, he found two real bugs among those three. Honestly marking what you did not review is not embarrassing — it saves your future self time. One more point: do not store long conversation logs as your handbook. That is an archive, not a handbook. A handbook is the few pages distilled from those conversations; the archive is there in case you need to look something up. You need both, but one cannot replace the other.

Day one back: follow this order

With the handbook written, do not improvise on restart day either — a fixed order saves the most time. Step one is to get it running: follow the thirty-minute startup checklist until you see a working interface locally. If it does not run, fix the startup problem first; do not casually change features at the same time, because mixing startup problems with feature changes is the easiest way to break the parts that worked. Step two is to read the status page and decision log, spending half an hour reloading "how far it got and why it was written this way" into your head, then reading the pitfall map so you know what not to touch. Step three is the first line of code — and it should be a small, safe change: fix a wording issue, fix a known small bug, or add a test where there was none. One small change running through successfully restores confidence and touch far more reliably than diving straight into core logic.

Step four is to update the handbook: fix anything the restart showed to be out of date, add newly found pitfalls, and write the restart date at the top. A handbook is not a write-once file; every restart is a chance to update it. On Shen Yizhou's second restart, two commands in the startup checklist had changed in newer versions; he fixed them on the spot, and the third restart did not stall at the same place. A handbook gets more accurate with use only if every use ends with a quick repair — not with complaints that it is out of date while nobody touches it. Step five is to set the next checkpoint: how far will this return go, at what point is it acceptable to pause again, and what must be added to the handbook before pausing. Pauses are not scary; what is scary is pausing without leaving a trace every time. As long as every pause is preceded by half an hour updating the handbook, each restart gets cheaper than the last.

How often to update, so it does not become the thing that rots

A handbook's biggest enemy is not failing to write it, but writing it and then abandoning it to go stale. The update frequency does not need to be high; it needs to be tied to the project's rhythm. Shen Yizhou's rules were three: after every release, spend fifteen minutes updating the status page and pitfall map, because releases are when "the situation changed but the handbook did not" most often happens; whenever you make a decision someone else would have made differently, add a decision-log entry the same day — do not save them up, because saved-up reasons get forgotten; and every month, whether or not there was a release, spend half an hour reading through the handbook, deleting what is clearly out of date and sharpening what is vague. Fifteen minutes plus half an hour is a low cost, but it keeps the handbook trustworthy on the day you actually need it.

One update moment is easily missed: just before you decide to pause. Most people stop passively — work gets busy, enthusiasm fades, and the project quietly slips away, and by the time they remember it months have passed. A better rule to set for yourself: whenever you sense a pause of more than two weeks coming, first spend half an hour writing a "pause note": how far it got, what the next step was supposed to be, and which sections of the handbook to read on return. That half hour is the highest-return investment in the whole handbook, because when you write it you still remember everything, and on return it becomes your navigation map. Shen Yizhou wrote one before every pause after that, even for a three-week break, because three weeks is enough to forget half the details.

A final word: keeping a solo project from rotting away does not depend on willpower. It depends on leaving a way back for your future self. Code will be forgotten, decisions will be forgotten, even why you started the project may be forgotten — but a few pages of continuity handbook will not forget. It does not need to be comprehensive or beautiful. It needs to do three things: get you running within a day, tell you what not to touch carelessly, and give you confidence when you change your first line of code. Spend an hour or two writing it while you still remember, put it in the most visible place in the repository — quite possibly the best-value investment you will ever make in that project. A project may pause, but it should not die from "coming back and no longer understanding your own work".

Restart acceptance checklist

Once the handbook is written, check it against this list and fill any gaps. First, is the handbook visible the moment the repository is opened, under a name recognizable at a glance? Second, can someone who has never touched the project — or you three days from now — get it running within thirty minutes by following the startup checklist, with every step stating what success looks like? Third, does the status page state clearly which parts are half-built and which have known pitfalls? Fourth, does the decision log contain the decisions most likely to be wrongly "fixed", each with its reason? Fifth, is the pitfall map dated, and does it include temporary workarounds? Sixth, are accounts and keys recorded by location only, with no secrets in plain text? Seventh, are AI collaboration constraints and the not-closely-reviewed list written as their own section? Eighth, is the pause-note rule set, so that before the next pause of more than two weeks you write a page first? If all eight pass, the handbook is genuinely usable. The hour or two spent writing it buys back a future afternoon that would otherwise be spent digging through old history — a bargain by any measure.