K-3.5 What Lasts When People Can Leave

The Field Manual defines a moat as "whatever lets you keep earning good margins after competitors notice you're earning good margins." The two strongest moats it describes both work by holding people in place. Kindling is written so that a builder cannot hold anyone. §5.3: "A Profile owner MAY withdraw consent and remove themselves from any Pool at any time through the messaging channel (§6). Implementations MUST process withdrawal within 60 seconds of receipt." The project's Why page puts the first of its twelve shifts in one line: "Pools are a commons, not a moat."

That leaves you less to build than Chapter 3.5 teaches, and what is left is sturdier. Kindling defines no chargeable surface between two people (§1.3, a stated non-goal). The parts of Hamilton Helmer's framework that never depended on trapping anyone still work. Spec references are to v0.1.1, the version stated as of October 4, 2026.

The two Powers the protocol takes away

Switching costs. The Field Manual's table gives the barrier as "Leaving costs them time, money, data or risk." On Kindling, a Pool must process a person's leaving within 60 seconds of receipt (§5.3), and leaving takes nothing with it, because a builder never held what matters. "A Profile is whatever the owner publishes at a URL" (§2.1). Photos stay on the owner's page: "Photos MUST be referenced by URL only. Kindling and Pools MUST NOT store photo bytes." (§2.5) Chapter 3.5 already warns "Don't manufacture switching costs by crippling export." Kindling removes the thing that would need exporting. The Why page names the result: "Apps compete on how well they treat you, not on how hard they are to leave."

Network economies held by an app. Chapter 3.5 says of networks: "A copycat can clone the software. The people on it stay where they are." On Kindling the people are not on your client. They are in Pools, and the Why page describes those as "an open list that anyone can host, and any app can read a public one." The people in a Pool "stay findable whichever app anyone uses." The network effect is real. It belongs to the Pool and its curator, and your client reads it like every other client does.

Cornered data, turned around. Chapter 3.5 lists "Rights-cleared proprietary data" as a cornered resource for a small founder. A builder cannot corner profile data on Kindling, and should not try. Profiles live on their owners' pages (§2.1), a page carrying the noindex directive stays out of everything ("Compliant Pools and crawlers MUST NOT include such a Profile in any Pool, registry, or discovery surface," §2.7), and every entry in a Pool exists only because someone said yes (§5.1). Whatever data advantage you build has to come from your own work, such as an evaluation set for your parser.

What still works

Counter-positioning. The Field Manual calls it "the solo founder's best weapon": a new business model where "The incumbent won't copy it, because copying would damage their existing business." The protocol site states the position Kindling takes against the apps it was written in answer to: "They make money on the wait, not the meeting." A client that reads open Pools earns nothing from the wait. An app whose revenue depends on the wait can copy that only by giving up what it charges for. This is a reading of the sites, not a sentence in the spec. Chapter 3.5's warning holds too: counter-positioning "erodes once the incumbent decides the pain of copying is smaller than the pain of losing customers. It buys you years."

Trust you can show. Chapter 3.5: "Anyone can generate a product, a website and a thousand fake reviews in an afternoon. A reputation built over years is worth more for it." Kindling makes part of trust visible by rule. Verification level "MUST be visible to Askers" (§4.1), and "a v1-conforming UI MUST render it alongside every Profile" (§4.5). The rest is your record. People can leave at any time, so every month they stay is a month you treated them well.

Process power in what nobody sees. Chapter 3.5 puts the AI-era version plainly: process power "lives in what isn't visible," and "Reliability itself becomes the process advantage." For a builder that means a withdrawal path you have timed under 60 seconds (§5.3). It means a parser that records what it guessed: "A parser MUST fill extraction_source whenever it infers any field." (§2.3) And it means conformance you can show section by section, against the four classes in §11. K.1 maps each class to the sections that bind it.

Distribution. Chapter 3.5 calls distribution "the moat most available to solo founders and the one they most often neglect." On Kindling it runs through the registry and the well-known file. Chapter K-7.1 covers both.

The shutdown test, for a builder

Chapter 3.5's shutdown test asks what happens if a supplier you depend on turns hostile or disappears. A builder on Kindling depends on fewer things than a builder on a platform, and they are different things. Write one paragraph for each scenario below, describing the next 90 days.

1. The maintainer stops. "TranquilTech, through the Mycelial team, holds the initial maintainer role" (GOVERNANCE.md). The protocol site's answer is "If TranquilTech disappeared tomorrow, the Pools would keep working." Check that your client would. It should still read manifests, still honor withdrawals, and still validate against schemas you keep a copy of.
2. The registry never opens. "Send the link and the registry lists it" was Planned on October 4, 2026, with no live endpoint (K.1). §8.4 says the public registry "MUST NOT be the only way a Pool is discoverable." A client that finds Pools only through one registry has a single point of failure the spec told you not to build.
3. Your email path fails. Messaging rides on email in v0.1 (§6.1), and richer transports "MUST preserve email as a fallback through v1.x" (§6.4). If your sending provider cuts you off, handshakes and withdrawal notices stop. Know how long it would take you to move.

If your client also calls a language model, for instance to answer questions over Pools, keep Chapter 3.5's original three model scenarios as well: price tripled, access cut off, feature shipped by the provider.

The switching test, turned around

Chapter 3.5's switching test asks your best customer what they would lose by leaving. It reads the answer "nothing, really" as having "no switching costs," so you are "competing on price and features every month." On Kindling that answer is the design. Ask the other question instead: what makes a person keep choosing your client when leaving costs them nothing? If every answer is about how your client treats them, you have built the only kind of advantage the protocol leaves room for. If any answer is about something they cannot take with them, check it against §2.5 and §5.3 before someone else does.

Field exercises

1. List everything your client keeps that a person cannot take with them when they leave. Done when the list is empty, or every item on it has a §2.5 or §5.3 answer you can quote.
2. Write the three shutdown paragraphs: maintainer, registry, email. Done when each has a concrete 90-day impact and one mitigation you can start this month.
3. Time one withdrawal in your client, end to end, with an invented profile. Done when it completes in under 60 seconds by the clock and you have written down how you would notice if it stopped doing so.
4. Ask one person whose page your client reads what would make them keep choosing it. Done when you have the answer in their words and none of it depends on making leaving harder.
5. Mark your client against the four Powers this chapter keeps: counter-positioning, trust, process power, distribution. Done when each is marked "have," "could build" or "not available," with one sentence of reasoning for each "have."

---

Rewritten for the Kindling edition from Chapter 3.5 of The Solo Operator's Field Manual. The full chapter is on solo.joshwolf.net. © 2026 Josh Wolf, licensed under CC BY 4.0. Quotations from the Kindling Protocol Specification v0.1.1: © 2026 TranquilTech and Kindling spec contributors, CC BY 4.0, marked where shortened.