Projects do not end. They tail off. The last real decision was three weeks ago, the final invoice went out on Tuesday, and at no point was there a moment where anybody said "that's done".
Which means the notes never get closed either. They sit in the state they were in on the busiest day — half-finished thoughts, meeting fragments, four documents with similar names — and that is the state you find them in eighteen months later when somebody asks why you chose the thing you chose.
An hour at the end fixes it. Here is what to do in that hour.
Write one note that explains the whole thing
If you do nothing else, do this. One note, at the top of the project's folder, written for a stranger — who is you, in a year, having forgotten everything.
Five headings, none of which needs to be long:
- What this was. Two sentences. What we were trying to do and for whom.
- What actually happened. What shipped, when, and how it differed from the plan.
- The decisions that shaped it. The three or four real forks, with the reason each went the way it did.
- What I would do differently. Written now, while it still stings enough to be honest.
- Where everything lives. The repository, the shared drive, the invoice, the contract, the final assets.
That last heading is the one people skip and the one that gets used most. Notes have a habit of outliving the systems they refer to, and "the files are in the client's Dropbox, in a folder called Handover" is the difference between recovering a project and reconstructing it.
Keep the decisions and the numbers
When you go back to old project notes, you are almost always looking for one of two things: why something was decided, or what a number was.
Decisions age well and are impossible to reconstruct. The estimate you gave, the option you rejected, the constraint that ruled something out, the thing the client insisted on against your advice. Six months on, nobody remembers which of those was true, and a note that records it is worth more than anything else in the folder. If you already keep a decision journal, the close-out is where you make sure the project's decisions actually got into it.
Numbers age well too, for a different reason: they are what you will price the next project from. How long it took, what it cost, how many rounds of revisions, how many meetings. Write the real figures down at the end, before optimism edits them.
Bin the scaffolding
Most of what a project accumulates is scaffolding: useful during, meaningless after.
- Scheduling messages. "Can we move Thursday" is not a record of anything.
- Superseded drafts, once the final version exists and you can say where.
- Notes-to-self that were done weeks ago.
- Half-written thoughts you can no longer decode. If you cannot tell what it meant now, you will not do better later.
- Duplicate copies of documents that live properly somewhere else.
Deleting feels risky, so a compromise that works: one note called Raw holding anything you cannot bring yourself to throw away, and everything else gone. The point is not saving disk space, it is that the folder should be readable at a glance. A folder with six things in it gets opened. A folder with sixty gets avoided, and the six good things in it are lost inside the fifty-four.
Name it so it can be found
Search is the only realistic way you will find this again, so write for search.
Put the year and the client or project name in the top note's title — 2026 Fernbank rebrand — close-out beats Summary. Use the words you would actually type in a year, which are usually the client's name and the thing you built, not your internal codename. If your app has tags, one tag for the client and one for the year is plenty.
The general rule: a note's title should contain the words a future stranger would search for. You are that stranger. Searching your own notes gets dramatically better when the titles were written with searching in mind.
The awkward bit: people
Two things worth capturing that are not about the work.
Who was who, briefly. Names, roles, and the one thing about each that made working with them go well or badly. When the same client comes back in two years, this is the note that stops you re-learning it.
What you would need to say yes again. Whether you would take this work again, at what price, with what changed. Write it on the last day, because the answer on the last day is more honest than the answer when the next enquiry arrives and you are quiet.
Be careful about what goes in here about other people — a close-out note is a work document that may be read by others, and some things do not belong in your notes at all.
When there is a handover
If somebody else is picking this up, the close-out note is most of the handover, but not all of it: handing over your work needs the things you know that are not written anywhere — the flaky step, the person who actually approves things, the workaround everyone forgot was a workaround.
Do that pass separately, and do it after the close-out, because writing the summary is what reminds you of them.
An hour, once
The whole thing takes about an hour and it is an hour nobody schedules, because it happens exactly when the project has stopped being interesting and the next one has started being urgent.
The argument for it is not tidiness. It is that the two most expensive things in professional work are re-deciding something you already decided and re-learning something you already knew, and a project without a close-out guarantees you will do both — usually in front of the client who is asking you to explain yourself.