Your Stack Does That / A field note from the launch
The most important line in the Cancel Ledger says “Kept.”
A slogan tells people what might change. A public ledger lets them see what actually changed—and what had a good reason to stay.
Three lines. Two different answers.
The first three entries in the Cancel Ledger report a grammar checker replaced, a social media scheduler replaced, and a password manager kept. That last line matters most to me.
I have just published Your Stack Does That on GitHub. The project takes the argument of my earlier essay and gives it somewhere to meet experience: a catalog of needs a stack can address, a test to run before buying another subscription, and a ledger of what people replaced or retained.
If every answer were cancellation, the ledger would tell us very little. We would have built a place for agreement. A useful test has to be able to return an answer its author did not come there to celebrate.
Source: the repository’s three launch-day ledger files, reviewed September 6, 2026. These are reported experiences, not independently audited results or a representative survey.
The work can move. The responsibility may stay.
The Stack Test asks whether a connector, a skill, or a scheduled task could do the job. Then it asks whether a separate relationship with a company is justified and whether the thing in question holds a record you need.
That second half is where the argument becomes useful. Getting help with a record does not automatically replace the service responsible for keeping it. A new way to work with information is not, by itself, a reason to move its custody.
The password-manager entry makes that boundary explicit. The project records a reason to retain the service. It does not treat every recurring charge as proof that someone failed to set up their stack.
The goal is to remove a dependency only when the work no longer depends on it.
That is my practical reading of the test. The ability to produce an output once is a beginning. Replacement means the necessary job continues to get done, with the quality, access, and responsibility the person actually needs.
“With setup” belongs in the headline.
The social-scheduler entry is valuable because it leaves the inconvenience visible. It reports a scheduled task for drafting and connectors where they exist. For one of the two networks in that account, posting still involves pasting by hand. The subscription went away. All the work did not.
Someone reading that can make a real decision. Manual posting might be a perfectly acceptable trade. For someone else, it could be the feature they were paying to avoid. Both responses are reasonable.
The contribution guide requires a Does entry to explain the need, the old purchase, the stack’s role, and how the work happens in plain terms. It also asks contributors to name the setup and the rough parts. Those requirements make an entry useful to the next person. The format is public.
What would make your experience useful?
Open each question before writing a contribution.
What actually ran?
Describe the task you completed and the parts of the stack you used. Separate a tested workflow from an idea for one. The next person needs to know where your evidence begins.
What did you still do yourself?
Name the setup, review, copying, missing access, and recurring maintenance. A saved subscription and a fully automated workflow are different outcomes.
What did you decide to keep?
Explain which responsibility or capability remained valuable. A retained service can teach the next contributor where replacement stops.
These are questions I want readers to carry into the project. Better descriptions will help more than bigger claims. A small success with a clear boundary is something another person can try.
Let the evidence travel.
The repository contains 36 Does entries and three ledger lines in the version I reviewed today. That is a starting catalog, not evidence that 36 workflows have been reproduced across every provider. Availability still depends on the tools, access, setup, and judgment involved.
The interesting design choice is how easily the knowledge can leave the website. Contributions are plain text files. The project’s builder produces web pages along with RSS, a JSON feed, and structured catalogs. Its check-back page describes having a stack look for additions on the reader’s schedule.
This fits the larger idea. Knowledge about a capability should be available where someone can use it. It does not have to remain inside the page that first explained it.
The repository releases its contents, including the slogan, under CC0. Its contribution rules ask for provider-neutral descriptions, honest setup requirements, and no sales pitches. Those are choices about the kind of public resource this can become: something people can reuse and improve, with enough detail to disagree productively.
The next useful contribution might be an ordinary task that now takes less effort. It might be a missing connector that keeps a promising idea from working. It might be a service someone tested and decided to keep. Each can make the next person’s decision better.