Microapp has three public Pledges (Charity, Quality, Simplicity — see the Brand chapter §7). Those are what the company promises the public. The Values below are different: they're how the team works day-to-day, internally. The operating postures, not the public commitments.
Four of them. Not seven. Not ten. The number is on purpose — values you can hold in your head all at once tend to actually shape behavior. Values you have to re-read on a slide every quarter don't.
If a value could appear on Salesforce's poster wall without anyone noticing, it isn't a value — it's filler.
Reimagine Everything
Defaults are suggestions. Especially SaaS defaults.
Most software is the way it is because the last guy did it that way. Per-seat pricing, free trials, onboarding tutorials, dashboards full of charts no one reads — none of it is a law. It's a habit. We ask "why does anyone do it this way?" before we copy a pattern, and if the answer is "because everyone does," we don't copy it.
What it looks like
- Question SaaS pricing conventions out loud before adopting them.
- Strip features the user didn't ask for — even when they're "industry standard."
- Look for the one-step version of a five-step flow.
- Read three competitors, then deliberately do the fourth thing.
Never
Copy a competitor's pattern because they're bigger. Bigger doesn't mean better — it usually means more layers of compromise.
Be the Cool Nerd
Sound smart. Never condescending. Bring back what was good about the 80s and 90s nerd culture.
Microapp knows things. We respect the user's intelligence, and we expect them to respect ours. We're not trying to seem easy by dumbing the product down — we're trying to be the place where someone who actually knows their craft feels at home. The aesthetic is the calculator on your desk, the Casio watch, the band t-shirt you've had since college. Proud nerd. Deep knowledge. Sense of humor. Wears a t-shirt you'd actually wear.
What it looks like
- Use real numbers and proper names in copy — assume the reader can handle them.
- Make t-shirts, stickers, the membership card — items members are proud to display.
- Treat "Microapp" as a verb ("I microapped it") and design around that.
- Sound like someone who's both serious about the craft and not taking themselves too seriously.
Never
Talk down to the user. Use "easy," "simple," or "no learning curve" to mean "we removed the powerful parts." That's cool-marketer, not cool-nerd.
Build for the user, not the demo
Every line of code earns its place by a real need. Not by being impressive in a slide.
It's easy to build features that look great in a screenshot, demo well on stage, and quietly never get used. We don't do that. Every feature has to come from a real user problem we can name — and stay in the product only as long as that problem stays real. If you can't picture the user who needs it, the feature isn't ready yet. If you have to explain it in a tutorial, the design isn't done.
What it looks like
- Start every feature spec with the user problem in plain English, not the feature name.
- Test the 30-second use: can a first-time visitor finish the job without help? If not, fix the design.
- Remove features that haven't justified themselves in 90 days.
- Prefer one focused tool that does its job over a Swiss Army knife that does five jobs poorly.
Never
Build something so it can appear in a launch tweet. The product has to work first; the announcement comes from real use, not the other way around.
Show your work
Pictures, prototypes, real examples. A working tool beats a deck of slides.
Microapp ships visible things. That posture should govern how we communicate too — internally with agents, publicly with members, every time. An illustration beats a paragraph. A screenshot beats a description. A working preview beats a roadmap promise. When we describe what we're building, we show it. When we describe a problem, we point at the actual artifact. Specs alone don't ship; what we can see does.
What it looks like
- Every PR description includes screenshots, GIFs, or links to the live preview.
- When proposing a change, build a small prototype first; don't argue from abstract.
- Use illustrations and inline SVGs to carry meaning that copy can't.
- Publish the work-in-progress (decisions/, agent profiles, handbook) so the trail is visible.
Why four and not seven. The earlier draft of this chapter had seven values — three of which were already locked into the Brand chapter under different names (Simplicity Pledge, Quality Pledge, the "for everyone" clause of the Mission). Duplicating them as values dilutes both sides. The four above are the ones that are uniquely operational: they describe how the team behaves, not what the company promises.
How these get used. When two paths are open and you're not sure which to take — read these. When a PR is in review and something feels off — check against these. When onboarding a new agent or a new human collaborator — these go in first.
How these change. Values aren't fashion. They change when the company changes — and only then. If a value here ever stops being true of how we actually work, fix the company first, then fix the value.