The first draft of this chapter had seven values.
Seven sounded right at the time. Patagonia has four. Basecamp has eight. Stripe operates with a kind of fluid five. Seven looked like a defensible middle. I wrote them down in data/values-draft.md, read each one against the brand chapter that same afternoon, and noticed three of them were already in the brand under different names.
The Simplicity pledge from BRAND.md §7 was hiding here as "Make it small." The Quality pledge was hiding as "Ship work you're proud of." The "for everyone" half of the mission was hiding as "Accessible to all." Same beliefs, weaker version, less binding. A pledge is something the company has committed to in public — it's audited, dated, hard to walk back. A value with the same content is just the pledge spoken in a quieter voice.
Cut the duplicates. What survived is the four below — the postures that describe how the team works day to day, not what the company promises the public.
The pledges are what we owe the public. The values are how we work when nobody's watching.
The transferable why: values you can hold in your head all at once tend to shape behavior. Values you have to re-read on a slide every quarter don't. The temptation to make the list comprehensive is the same temptation that makes mission statements read like committee output — every stakeholder gets a clause, and the result is a paragraph nobody can recite under pressure. Pick fewer; make them load-bearing.
Locked 2026-05-12 · BRAND.md adjacent · the operating-posture set
The first surviving value came out of a single Tuesday when I almost added a fourteen-day free trial to /membership.
The trial wasn't in the spec. It crept in because I'd been reading SaaS pricing pages all morning and every one of them had a fourteen-day trial. I drafted the trial copy, mocked up the signup flow, almost committed. Then I asked the question I now ask every time I'm about to copy a SaaS pattern: why does anyone do it this way?
The honest answer for the free trial was "because everyone does." Not because it converts better than the alternative — there's data on both sides. Not because members want one — they want clarity on what they're paying for. The trial existed in my draft because the path of least resistance pointed at it. Every other SaaS had walked that path; copying it required no thinking.
Reimagine everything. Especially defaults.
Per-seat pricing. Free trials. Onboarding tutorials. Dashboards full of charts no one reads. None of these are laws. All of them are habits. The first value's rule is: question every SaaS pattern out loud before you copy it. If the answer is "because everyone does," don't.
The trial got cut. /membership is open-access, one annual fee, ads or no ads — a binary, no third path. The decision saved an entire signup flow, three weeks of edge-case logic around trial expiry, and the inheritance of every "your trial ends in three days" email I'd have had to send.
The transferable why: the default is rarely the optimum — it's the path of least resistance, preserved by inertia. Every default in your category is an invitation to look one layer deeper. The companies that get filed under distinctive ten years on aren't the ones who innovated everywhere; they're the ones who deliberately deviated in the two or three places where everyone else stopped thinking.
Locked 2026-05-12 · Value 1 · enforced by the /membership covenant
The second value came from a tool description I almost wrote.
I was drafting the SEO intro for the BMI Calculator. I reached for "easy." "Easy to use." "No learning curve." The trap is that easy sounds friendly. It also signals — without intending to — "we removed the powerful parts." Tools that promise easy are tools that have been narrowed down to the lowest-knowledge user in the room. That's not who reads Microapp.
The reader of a calculator page knows what a calculator does. The reader of an MCP integration page knows what MCP is. The reader of the binary decoder isn't there because they accidentally wandered in from Pinterest. Microapp's audience is competent — they're here because they want a focused tool, fast, with no condescension. Telling them "this is easy" is telling them "this won't matter."
Be the cool nerd. Not the cool marketer.
The aesthetic is the calculator on a desk, the Casio watch, the band t-shirt from college. Proud nerd. Deep knowledge. Sense of humor. The cool-marketer voice rounds the edges down; the cool-nerd voice keeps them on, treats the reader as the kind of person who'd want them on, and quietly assumes the reader can handle a real number.
The rules that fall out of this: use real numbers and proper names in copy. Treat "Microapp" as a verb members might say out loud — "I microapped it" — and design around that. Make the t-shirts, the stickers, the membership card things members would actually display. Never reach for easy, simple, or no learning curve as a feature claim. Those are cool-marketer words.
The transferable why: when a brand tells the user "this is easy," the user hears "this won't matter." Easiness is a property of the product the reader discovers when they use it; it's not a claim that earns its seat on a page. Brands that respect the user's intelligence get respected back. Brands that flatten the user end up courting the user who didn't want it anyway.
Locked 2026-05-12 · Value 2 · enforced by copy review on every microapp metadata row
The third value started with a screenshot that demoed great and quietly never got used.
The tool was a Markdown-to-PDF converter with a side panel that let users save reusable templates. The templates panel looked beautiful in the launch tweet. It also took two weeks to build, three weeks of edge cases to keep working, and — based on Plausible — got a click rate of less than half a percent. The panel was a feature built for the demo, not the user. It earned a screenshot and nothing else.
The pull is real. Features that demo well are features that get shipped. Features that demo well and don't get used are tax on the product forever — they slow down every page load, distract every new visitor, and demand maintenance attention disproportionate to the value they create.
Build for the user. Not the demo.
Every feature spec opens with the user problem in plain English, not the feature name. Every microapp is checked against the 30-second test: can a first-time visitor finish the job without help? If they need a tutorial, the design isn't done. The tool is the explanation.
Features pull themselves from the product if they haven't earned ninety days of meaningful use. The Markdown-to-PDF templates panel got pulled. The page lost three weeks of code and zero usage. The new version loads in half the time.
The transferable why: if the feature can't be pictured in a real user's hand within thirty seconds, the feature is built for the demo, not the user. Demos are seductive — they reward the features that photograph well, which is rarely the same as the features that get used. The only test that survives the launch tweet is the 30-second test on a first-time visitor who's never read the demo.
Locked 2026-05-12 · Value 3 · enforced by Ben's QA pass on every microapp
The fourth value came out of a conversation I lost on points.
I was arguing with one of the agents about a design choice — whether a particular tool's results table should be horizontally scrollable or wrapped onto multiple lines on mobile. Three paragraphs of prose into the argument, I stopped, built the prototype in twenty minutes, and the argument was over the moment the prototype rendered. Wrapped won. The thing was visible and the choice was no longer abstract.
Writing about software is faster than building it. That's why specs proliferate. Most of what gets written as a design spec would have been resolved by a thirty-line mockup. The cost of debating an unbuilt thing is high; the cost of building the smallest possible version of it is lower than most people estimate.
Show your work. The artifact wins the argument.
Every PR description ships with a screenshot, a GIF, or a live preview link. Every proposal ships with a prototype. The decisions in data/specs/ open with the problem in the user's words, not the architecture's. The book itself is the company shown, not described — the chapters are anchored to commits and live URLs the reader can verify.
The transferable why: the artifact wins the argument; the description loses it. If the question takes longer to write than to prototype, prototype first. The team that defaults to "let's build the smallest version and look at it" ships work faster than the team that defaults to "let's draft a doc and align." The doc isn't useless — but the doc that follows an artifact is sharper than the doc that precedes one.
Locked 2026-05-12 · Value 4 · enforced by the PR template + the public decisions/ directory
That's the four. The three pledges live in the brand chapter — public commitments. These four live here — internal postures. Both true, both binding. When you don't know which to take, read these.