Kill criteria written in advance
A threshold written down today, before sunk hours make you defensive about the outcome, is the only kill criterion you will actually follow later.
The rate is in the ledger now, and possibly two of them side by side. What the ledger still does not have is the number that ends something — the rate, or the customer count, or the month, at which you stop arguing and shut a project down. This lesson writes that number, and then it does the harder half: what actually has to happen on the day the number gets hit.
The triage module already made the case for writing kill criteria early, with a real source behind it, and that argument is not being made again here. What that lesson left open is a single line in its own exercise: for every kill verdict, name what happens to its users and its domain — a redirect, a shutdown notice, a data export, a transfer, letting the registration lapse. That was a checklist bullet with nothing behind it. This lesson is what is behind it.
What a kill criterion has to contain
A criterion is only worth writing if a stranger could apply it. The test is not whether the sentence sounds decisive when you write it; it is whether two people reading it on the date, with the ledger open in front of them, would reach the same answer about whether it fired. Almost every criterion people actually write fails that test, and it fails for one of three reasons.
- A measurable — the specific figure you will read, named precisely enough that you know where to read it from. “Traction” is not a measurable. “Paying customers on the last day of the month” is.
- A threshold — the value of that measurable that separates continue from stop. One number, on one side of which the answer changes.
- A date — when the reading gets taken. Not a season, not “once things settle down”: a day you could put in a calendar.
That three-part shape is this course’s own construct, not a finding. Kill criteria are not a regulated or standardised concept and there is no authority to appeal to about what makes one usable — the nearest thing is the state-and-date argument the triage module already borrowed and credited. The three parts are here because each one names a different way a criterion gets argued out of existence later, and you should treat the split as a working tool rather than as something anybody validated.
A threshold is a number you can be wrong about
The threshold is where honest criteria die, because a threshold is a commitment and a feeling is not. “If it still feels like a drag” is unfalsifiable on purpose: on the day, you will be the one deciding whether it feels like a drag, and every hour you spend on the project between now and then will be arguing on its side. You do not have to guess at how many that is. Your ledger has an hours-sunk column, it only ever goes up, and whatever it reads on the date is the size of the case against your own judgement.
You already have the measurable this course would pick. The effective hourly rate — monthly profit over every hour the project takes, acquisition included — is the one figure in the ledger with your own time in the denominator, and a threshold on it reads cleanly: if on (date) the effective hourly rate is under ($X), this is a kill. Pick the dollar figure by comparison, the same way the unit-economics work made you write a comparison beside the rate itself: your contracting rate, an hour of the day job, or the value of an evening you did not spend working.
Your ledger holds no revenue actuals, and nothing here needs any. The rate you built was an estimate stacked on one measured maintenance number, and a criterion written against it is a criterion about a future reading, not a current one. That has one consequence worth writing into the criterion itself: the date has to be far enough out that the measurable will actually exist by then. A threshold on paying customers, judged six weeks from now on a project that has never had a checkout page open, is not a kill criterion. It is a way of arranging to fail on a technicality.
Retrieval check
Your kill criterion says “if it isn’t working by spring, I’ll shut it down.” What are the three things wrong with that sentence?
Check your answer
No measurable, no threshold, no date — and it is missing all three at once, which is why it feels like a decision and functions like a mood.
“Working” is not a measurable: nothing in the ledger has that name, so on the day you will be free to pick whichever figure flatters the project. Nothing is the threshold: there is no value on one side of which the answer changes, so any reading can be argued into a pass. “By spring” is not a date: spring runs three months and arrives every year, so the reading can be postponed indefinitely without ever admitting it was postponed.
Each gap is a place to argue with yourself later, and the sunk hours will do the arguing. Written properly it reads: on May 1, if the effective hourly rate is under $25, this is a kill.
Sunset mechanics: what happens after it fires
A criterion that fires and produces nothing is worse than no criterion, because now you have written proof that you decided and did not act. What follows is the operational half — the part the triage checklist named as five options and never explained.
One boundary before any of it. This course names a decision and points at where to get real advice. It does not give legal advice, and nothing below is legal advice. What the sections that follow do is quote the operative text so you know what the words actually say, and mark clearly which claims are the statute speaking, which are a plain reading of a bright-line test, and which are the kind of question you take to a lawyer rather than to a lesson.
The data you are holding
The European Union’s data portability right lives in Article 20 of the General Data Protection Regulation, and paragraph 1 gives the data subject:
“the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format” (Art. 20(1) GDPR, as rendered by gdpr-info.eu)
Two things about that citation, said plainly rather than buried. First, the text above was read off gdpr-info.eu, not off EUR-Lex. EUR-Lex, the Official Journal’s own site, would not serve the regulation to any of the tools used to write this lesson — repeated attempts across four URL formats, every one of them returning an empty body. gdpr-info.eu is a widely cited third-party rendering that describes itself as the Regulation (EU) 2016/679 text “in the current version of the OJ L 119, 04.05.2016; cor. OJ L 127, 23.5.2018”, and its Article 20 page carries a published date of 13 July 2016 and a last-modified date of 28 March 2018 in its own metadata. That is a mirror describing its own provenance, which is not the same as the Official Journal, and if a decision of yours turns on the exact wording, get it from the Journal or from someone whose job it is to read it.
Second, the article is narrower than its reputation. The right applies only where processing rests on consent or a contract and is carried out by automated means; it covers data the person provided, which is not the same as everything you hold about them; direct controller-to-controller transfer is owed only “where technically feasible”; and paragraph 4 says the right “shall not adversely affect the rights and freedoms of others.”
Here is the part that matters for a shutdown, and it is a fact about the text rather than an interpretation of it: Article 20 says nothing about closure, wind-down, or insolvency. There is no shutdown clause, no special duty that switches on when you announce, and equally no exemption that switches on either. The obligation is identical on the day you launch and the day you turn it off. Read it forwards and it stops being a shutdown problem at all: if you have no way for a user to get their data out, you did not acquire that problem by deciding to close — you had it the whole time, and closing is just when it becomes visible.
California’s equivalent sits in the Civil Code at §1798.130, not at §1798.100 where people tend to look for it. Subdivision (a)(2)(A) requires disclosure to a consumer:
“in a readily useable format that allows the consumer to transmit this information from one entity to another entity without hindrance” (Cal. Civ. Code §1798.130(a)(2)(A))
and subdivision (a)(3)(B)(iii) asks for the specific pieces of personal information “to the extent technically feasible, in a structured, commonly used, machine-readable format that may also be transmitted to another entity at the consumer’s request without hindrance”. That is the live text on California’s own legislative site, which stamps the section “Amended by Stats. 2025, Ch. 67, Sec. 26. (AB 1170) Effective January 1, 2026.”
The two statutes then diverge in a way worth being precise about, because it is the difference between a question you can answer and one you cannot.
- The California thresholds are bright-line, and you can read them yourself. The state Attorney General’s own page, updated 28 August 2026, says the Act applies to for-profit businesses doing business in California that meet any of three tests: “Have a gross annual revenue of over $25 million”; “Buy, sell, or share the personal information of 100,000 or more California residents or households”; or “Derive 50% or more of their annual revenue from selling California residents’ personal information” (California Attorney General). A one-person project taking small payments clears none of the three, and saying so is a plain reading of a numeric test rather than a legal opinion. It says nothing about Virginia, Colorado, Connecticut or any other state with its own act and its own numbers.
- GDPR has no size floor at all, and its applicability is not a question this lesson can answer. Article 20 carries no revenue threshold and no small-business carve-out: on the text, a $9-a-month product with three European customers is a controller in exactly the way a large company is. Whether the regulation reaches you turns on things like establishment and whether you are offering goods or services to people in the EU — fact-specific questions with real answers that depend on your particular situation. That one is a lawyer’s question, not a lesson’s. If you have any European users at all and you are about to delete their data, it is worth an hour of somebody qualified rather than an afternoon of search results.
Where people get burned
Do not read the paragraph above as permission. “Probably not covered by the California statute” is a statement about three numbers in one state’s law, and it is the only such statement this lesson is willing to make. It is not a verdict on any other jurisdiction, on your payment processor’s contract, on whatever your own privacy policy promised, or on what you owe someone as a matter of decency — which is the next section, and which no statute was ever going to settle.
A shutdown that was done properly
Relay.app, a workflow-automation product, announced its wind-down on 16 July 2026 and put the whole thing on one page. It is not a one-person side project, so read it as a template rather than as a peer — but every mechanism in it scales down to a shelf project, and having them all in one announcement is what makes it worth studying.
- Notice, staggered by what people had paid. Free accounts kept working for 30 days, to 15 August 2026; paying customers kept full access for 60, to 14 September 2026. Money bought a longer runway, which is the correct direction for that asymmetry to run.
- Charging stopped at the announcement, not at the end. Subscriptions were cancelled effective the day of the notice, and the company’s own words are that “you will not be charged again” while access continued free through the window.
- Refunds with a stated turnaround. “For annual customers, we will automatically initiate a prorated refund for the unused remainder of the current billing period. You should receive this refund within 5 business days.”
- An itemised export, in named formats. Workflows, sequences and MCP servers as JSON with their AI prompts; run history; tables as CSVs. Not “you can export your data” — a list, so a customer could check whether the thing they cared about was on it.
- An explicit deletion policy with a date attached. “Customer content and product data that you do not export will be permanently deleted at the end of the wind-down window”, and stored credentials and tokens for connected apps go with it.
Two caveats on that example, because it would be sloppy to hold it up without them. It is the company’s own announcement, which makes it a first-hand record of what was promised and not evidence about what was delivered. And the third-party write-up that surfaced it, published 16 July 2026 by Inbox Zero, is written by a company selling one of the migration destinations it recommends in the same article — useful for the announcement date, which it timestamps, and worth naming rather than treating as neutral coverage.
The domain is not a footnote
“Let the registration lapse” sounds like the cheap option and is really a decision to hand the outcome to a policy you have not read. For generic top-level domains that policy is ICANN’s Expired Registration Recovery Policy, binding on registrars and registries since 31 August 2013, and republished in its current form on 21 February 2024. Paragraph 2.2.1, subject to the applicable consensus policies and to the Registrar Accreditation Agreement, provides that “registrars may delete registrations at any time after they expire.” Paragraph 3.1 then gives a 30-day Redemption Grace Period after deletion, during which the name can be restored by the registrar that deleted it — and paragraph 3.2 requires the registry to disable DNS resolution throughout it.
Read together, those say that lapsing has no predictable date. The site stops resolving at a moment your registrar picks, every link anyone ever made to it breaks without a redirect, and after redemption ends the name goes back on the market for anyone — including someone who would like to inherit whatever reputation the name accumulated. If the project had users, the domain outliving the product by one paid year, serving a one-page notice and a link to the export, is a cheap and finite alternative. Decide which of the two you want on purpose, because the default is the first one.
What you owe the people who paid you
Strip the statutes away and there is a question left over that none of them answer: what does a person who gave you money for a thing deserve when you stop making the thing. The honest answer is that nobody authoritative has defined it. What follows is this course’s own position, assembled from what the Relay announcement actually did, and it is offered as a floor rather than as a finding.
- Notice with a date on it, sent before anything stops working, saying exactly when it stops.
- No further charges after the notice. Cancel the subscriptions the day you announce, not the day you close.
- A refund for time paid and not delivered, proportional and unrequested, with a turnaround you state.
- An export, itemised. Name the things and the formats, so somebody can check whether what they care about is on the list.
- A stated deletion date, so the export deadline is a real deadline and the data does not sit on a disconnected disk indefinitely.
None of that is expensive at your scale. A customer list short enough to read aloud is short enough to email one by one; the export is written once; the refunds run against a payment dashboard you already have open. It is only expensive if you have to invent it on the day — which is precisely why it belongs in the ledger now, beside the criterion that triggers it, written while the project is still alive and you are not also sad about it.
Now write both fields
Hands on
Write a kill criterion and a sunset plan for the pursued project
Done when: PORTFOLIO.md has Kill criteria filled in for the pursued project — one sentence naming a measurable, a threshold and a date — and a new Sunset plan field beside it covering notice, money, data, and the domain. Both are written from estimates and the one measured maintenance number, with anything estimated labelled as an estimate.
- Open
learning/monetizing/PORTFOLIO.mdand find Kill criteria on the pursued project. The field already exists and is blank — this is the step that fills it. - Write one sentence in the form on (date), if (measurable) is (above/below) (threshold), this is a kill. Use the effective hourly rate as the measurable unless you have a better one; the threshold is the comparison figure you already wrote beside that rate.
- Check the date against the measurable. If the figure will not exist by then — no launch, no customers, nothing to read — move the date out until it will, and write one line saying what has to have happened by then for the reading to be meaningful.
- Now read your own sentence back as if somebody else wrote it. If you can imagine arguing on the day that it did not really fire, find which of the three parts is soft and harden it. That argument is coming; the only question is whether you have already answered it.
- Add a new field: Sunset plan. The ledger does not carry this one yet — you are adding it, and every project you take money for gets one from here on.
- Under it, write four lines. Notice: how many days, and to whom, split by paid and free if you have both. Money: when charging stops and what gets refunded. Data: what people can export, in what format, and the date it gets deleted. Domain: renew and serve a notice, redirect, transfer, or lapse — one of those words, not a shrug.
- If the project has, or would have, users in the EU, add a fifth line naming that as an open question to take to a lawyer before the deletion date. Writing “ask someone qualified about this” in the ledger is a plan. Assuming it does not apply is not.
- Do the same for the second project in “pursue” if there is one, and for any project already carrying a kill verdict from triage — those are the ones with a shutdown genuinely pending.
- Bring the criterion and the sunset plan into the chat. I’ll push hardest on soft thresholds and on the data line, which is the one people write as “users can email me” and then discover, on the week they are closing, that they cannot honour.
What this does not cover
One project now has a written end condition and a plan for the day it fires. That is one project. What it does not tell you is what the projects you have not killed are costing the ones you are trying to grow — the tax a merely-alive project levies on everything beside it, in hours rather than in dollars, and how many of them one person can carry before the ones that are working start paying for the ones that are not. That is the subject that comes next.
Read this next — primary source
Art. 20 GDPR — Right to data portabilityRegulation (EU) 2016/679, as rendered by gdpr-info.eu rather than by EUR-Lex — free, about five minutes
Four paragraphs, and every limit on the right is inside them: the two conditions that have to hold before it applies at all, the words “provided to a controller” that quietly exclude everything you inferred about somebody, the “where technically feasible” on direct transfers, and the clause protecting other people’s data from your export. The version of this right that circulates second-hand is broader than the article, and the article is short enough that you never need the second-hand version. Read it once, in full, and you will know which half of the internet’s advice about it is wrong.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.