5.1.3 - How It Ends Is the Part People Remember

The ending

Turning it off is the easy part. The people using it are the part that takes notice.

The call

Stopping is not switching it off. It is telling the people who use it, giving them their data and keeping the promise you made when they signed up.

Sharpen the ending with AI

This is a Close idea, so the AI move is Run it for real. You can sharpen the decision here, but it only means anything against something that is actually running.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

Or copy this prompt into AI chat, replace the bracketed lines with your real project and keep the instruction exactly as visible here. It helps you put your stopping.md together by refining your three lines until somebody who did not build this could act on them.

An ending is a launch in reverse, so it has the same two halves. That is Where do you stop, for now? plus Name the risks yourself before users find them.

The same idea on a recipe card

A restaurant that closes puts a notice on the door weeks out, honours the bookings it already took and tells the regulars itself.

One that simply does not open leaves people standing outside holding a reservation. Same closure, two completely different things to be remembered for.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

Stopping gets treated as a technical act. Turn off the service, cancel the domain, archive the repo. All of that takes an afternoon and none of it is the part that matters.

The people still using a small thing are the ones who trusted you earliest, when there was least reason to. They are usually few enough to name. Turning it off quietly is the cheapest possible way to spend that trust, and it is spent permanently.

So the ending has the same two halves as the launch did. Who is affected, and what they are handed. The difference is that nobody is going to chase you for it, which is exactly why it gets skipped.

Make the ending concrete

Compare the version that sounds responsible with the version somebody could act on.

• Too vague: I will just turn it off, nobody is really using it.
• Concrete enough to test: Four people use it. They get four weeks' notice, an export of their whole log in a format they can open, the skill itself and an email from me rather than from the app. The policy was always theirs.

The second version could be carried out by somebody else. The first is a decision you have already made about people you have not counted.

Both versions come from consideredContent, the one project carried through all 35 ideas. See the project.

Check the ending

• Pass: Everyone still using it has been told, has their own data in a format they can open and knows where it went.
• Fail: It goes off and somebody finds out because it stopped working.

Nobody is going to chase you for this one. That is the whole reason to write it down.

What you'll walk away with

This post is about the closing decision: what you owe the people who trusted the thing. You'll come out with your own stopping.md naming who is still using it, what they are handed and what is left at the address afterwards.

Write it down

Your stopping.md is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again.

knowledge-base/product/stopping.md is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI.

Risk and mitigation

• Risk: The people using a small thing are the ones who trusted you earliest, and turning it off quietly is the cheapest possible way to spend that.
• Mitigation: Notice, an export they can open without you, and a person's name on the email rather than the app's.

Key takeaway

Nobody remembers what your side project did. They remember how it ended.

How to document your ending

Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this.

# The ending

## Answer
Who is still using it: [how many, and who]
What they get: [notice, their data, in what form]
What is left behind: [the domain, the repo, the page that explains]

## Evidence
How many people are actually using it, taken from the logs rather than from memory.

## Decision
What you are giving them and how long they get. What you are deliberately not doing.

## Risk
What breaks if this is wrong.

## Standing instruction
What the AI should do every time it touches this. For example: if I talk about shutting this down, ask who is still using it before helping with any technical step.