The One-Man Company Part II · Chapter 5 of 18

Part II · Chapter 5 of 18

The Microapp

What counts as a microapp — one purpose, any runtime. Four quadrants the catalogue grows into, three spec-stage filters, and the taste every microapp gives a non-member before asking them to pay.

The question that comes up most often is whether a particular thing counts as a microapp.

The first version of the answer was simple. "A microapp is a small web tool — a calculator, a converter, a generator." Worked fine for the first hundred tools, because the first hundred tools were calculators, converters, and generators. The framing broke the day I shipped the AI Hairstyle Analyzer, which is none of those — and it broke harder when a member asked whether Microapp would ever build something like Cromojo's automated indexing tool, which isn't a tool at all in the calculator sense. It's a service. It runs forever.

The early bound — *small web tool* — was a runtime bound. The trap is that as new runtimes emerge (AI compute, headless services, agents), a runtime-bound brand has to keep redrawing its boundary. The brands that survive are the ones that bound by what the product does, not how it's built.

One purpose, any runtime.

That's the actual definition of a microapp. The unifying constraint is that it does one job — the same one-job-done-right rule the brand chapter's Simplicity pledge already enforces. The runtime is implementation. A calculator that runs in the browser is a microapp; an AI hairstyle analyzer that burns OpenAI credits is a microapp; a background service that pings the Google Indexing API every six hours is a microapp; a single-purpose AI agent that watches your inbox for invoices is a microapp. Four different runtimes, four different cost shapes, one brand promise.

The transferable why: brand architecture should bound by what the product does, not how it's built. Runtime-bound brands fragment as new runtimes emerge — every two years another technology category appears and the brand has to decide whether to extend or split. Purpose-bound brands inherit each new runtime cleanly. Pick the cut that's invariant across implementation choices, and the brand survives the choices that haven't been made yet.

Locked 2026-05-18 · the one-purpose-any-runtime rule · adopted as Microapp's product definition


Cross the runtime axis with a second one — lifecycle — and the catalogue's whole future fits in a single grid.

A microapp is either one-shot (the user presses a button, gets an answer, the work ends) or continuous (the user configures it once, the work runs forever in the background). The runtime is either static (deterministic API calls or local computation, no LLM compute) or AI (LLM compute per run). Cross them and you get four quadrants — each one a class of microapp the catalogue can ship.

Static one-shot. Static continuous. AI one-shot. AI continuous. Same brand. Different runtime.

The stories that follow walk each quadrant — what ships there today, what it costs to run, how it's priced, what the next ten years of the catalogue look like as new tools land across all four.

Locked 2026-05-18 · two-axis taxonomy · runtime × lifecycle


Quadrant one is the bread-and-butter: static one-shot. Roughly 190 of the 200 microapps in the catalogue live here.

A unit converter. A binary decoder. A tip calculator. A regex tester. A JSON formatter. The user opens the page, the page renders instantly from static HTML, the JavaScript hydrates the widget, the user types or pastes, the answer appears. The work is deterministic, runs in the user's browser, and costs Microapp nothing per use. The CDN serves the page; no Worker is invoked; no compute is billed; no agent is involved.

Cost shape: zero per use. Pricing: free for everyone, ads for non-members, clean pages for members. The 30-second test is easy here — a calculator is the natural shape of the test. Almost every tool that ships in the first three years of the catalogue lives in this quadrant; it's the cheapest, fastest, and most defensible kind of microapp to add to the shelf.

Press button. Get answer. No meter.

The transferable why: the smallest viable unit you can ship is the one that gives you the most surface area to discover what's worth charging for. Catalogues that lead with their most-expensive products struggle to build the audience that justifies the price. Catalogues that lead with their cheapest-to-ship units accumulate users — and then upgrade the subset that needs more.

Locked 2026-05-18 · ~190 microapps · zero per-use cost · the default shape


Quadrant two is where the catalogue is starting to move: AI one-shot. Around ten microapps ship here today; the count will grow with the LLM landscape.

The AI Hairstyle Analyzer is the reference instance. The user uploads a photo, the tool calls a multimodal model, the model returns recommendations, the page renders the result. Same one-job rule, same 30-second test, same single-purpose discipline. The difference is the runtime: each invocation burns real compute — anywhere from a fraction of a cent to several dollars depending on the model. That cost has to be visible to the user before the run, paid in credits, capped at the budget the membership funds.

The model chapter covers the pricing mechanics: members get a generous monthly credit allowance, top-ups available at near-cost. Non-members get a one-time taste — a small allowance per device, a larger one with a free account — then membership is the only path past the taste. The brand promise (premium, one-purpose, member-funded) is identical to the static quadrant; only the per-run cost differs.

Same shape. Same rules. Credit price on the page before the run.

The transferable why: variable-cost products need variable pricing visible before the user incurs the cost. Hiding LLM cost in a flat subscription leaks money on the heavy users and prices out the light ones. Pre-disclosed metered pricing — credits visible per run — is the version that builds trust in the runtime and the brand at once.

Locked 2026-05-18 · ~10 microapps · credit-priced per run · AI Hairstyle Analyzer is the reference instance


Quadrant three is the one most catalogues never reach: static continuous. Zero microapps live here today. The shape is a tool like Cromojo's automated indexing — configure once, runs forever, single-purpose.

A microapp that keeps your sitemap submitted to Google and Bing. A microapp that monitors a competitor's pricing page and emails you when it changes. A microapp that watches a status feed and pings you when something breaks. None of these are calculators; all of them are one-purpose; all of them pass the 30-second-setup test. The work is deterministic — no LLM, just an API call or a poll on a schedule — but the lifecycle is open-ended. The microapp keeps doing its one job until the member cancels.

The pricing implication is sharper than in the one-shot quadrants. A continuous service compounds cost over time. Even at fractions of a cent per API call, a free-with-ads continuous tool would bleed compute while the member is asleep. The shape that holds the model intact is member-only.

Continuous services are member-only by economic necessity.

Not because Microapp wants to gate them — because the alternative leaks. The Membership funds the compute the service consumes. The brand promise stays whole: anyone can use any one-shot tool free; members unlock the continuous ones. The free-versus-member line moves from "ads or no ads" to "included or not" — and the boundary lands on the side of the cost shape.

The pricing currency is the same one that meters AI one-shots: credits. Credits are the universal compute unit across the catalogue — whether a credit gets spent on an LLM call, an API submission, a database write, or an alert email, it's the same unit, the same monthly budget, the same top-up path. A continuous microapp publishes its credit cost per action on its page ("0.01 credits per URL submission", "0.5 credits per directory sync", "1 credit per backlink scan"). The Membership comes with a generous monthly allowance that covers ordinary use; heavy users — someone managing 500 sites — buy top-ups at near-cost, members only. One usage budget across the whole catalogue, regardless of which microapps the member is running.

The transferable why: if a category of work compounds cost over time, gate it behind membership — not because you're greedy, but because the alternative is a leak that scales with usage. The leak gets worst exactly when the product is most successful. Pre-empt the leak by drawing the membership line at the lifecycle, not at the feature.

Locked 2026-05-18 · continuous services = member-only · credits as the universal currency


Quadrant four is the long-term direction: AI continuous. Single-purpose AI agents that run on a member's behalf, one job, one trigger, one outcome.

An agent that reads incoming email and files invoices into a member's bookkeeping software. An agent that watches a calendar and proposes meeting slots based on the member's stated preferences. An agent that scans a member's daily reading list and surfaces the three most-relevant articles. Each one runs continuously, each one uses an LLM to make decisions, each one does one job.

The temptation here is the temptation that gets every AI startup in trouble: the sprawling general assistant. The agent that "helps with everything." Microapp explicitly refuses that shape. A microapp is one purpose; an AI agent that's also a microapp is one purpose. The catalogue's long-term bet is that many small AI agents beat one big AI assistant — same way many small SaaS tools beat one big platform, for the same reason.

Many small agents. Not one sprawling assistant.

Pricing follows the same logic as quadrant three. AI continuous burns the most per-unit-time of any quadrant — compute plus state plus alerts plus integration. Member-only, included in the annual fee up to a generous monthly credit budget, top-ups at near-cost for heavy users. The membership becomes the unbundling of what Big Software sells as a sprawling subscription: instead of paying $50 a month for one tool that does ten things mediocrely, the member pays $99 a year for a hundred small agents that each do one thing well.

The transferable why: when a new technology lets you build a different shape of product — agents, in this case — the temptation is to build the maximalist version of it (the all-in-one assistant). The shape that wins long-term is usually the disciplined version, applied to many narrow problems. Same disposition as the early web: thousands of small focused sites beat the dial-up portals that tried to be everything.

Locked 2026-05-18 · AI continuous · the long-term direction · many small agents over one big assistant


One convention runs through all four quadrants, and the moment it almost broke was the moment I noticed it was a rule.

Drafting the spec for the first continuous microapp — a URL indexer, Cromojo-shaped — I got to the pricing section and wrote "member-only." Then I stopped. The previous three quadrants all had a way for a non-member to experience the product before paying. Static one-shots: full free access with ads. AI one-shots: a small allowance of free credits per device. The new "member-only" on continuous services would be the first quadrant where a non-member never gets to touch the actual experience. That breaks something the brand had been doing without naming.

The candidate fix was the SaaS default: a free trial. Seven days, then we'll need your card. I almost shipped it. The thing that stopped me was the consultant-word ban — "free trial" sits next to "unlock" and "empower" in the BRAND.md banned list, and not by accident. Trials are time-limited friction shaped to maximize anxiety. The user is on a countdown. The brand is signaling "you'll have to pay soon." That's the airline voice from the Voice chapter, applied to pricing.

The shape that survived the rewrite is different by one word.

Every microapp has a taste.

Not a trial. A taste. Scope-limited, not time-limited. Anonymous-friendly, signup-optional. The user gets the real product, at the real quality, in a smaller dose. No countdown, no card-on-file requirement, no "your trial expires in 3 days" email. The taste is the experience; the membership is the experience at scale.

The taste takes a different concrete shape per quadrant. Static one-shot: unlimited free use with ads on the page. The taste is the product. AI one-shot: a small free allowance of credits per device, larger with a free account, then membership for more — same shape The Model chapter already locked. Static continuous: a bounded run — monitor 1 URL instead of 100, watch 10 backlinks instead of 10,000, sync to 3 directories instead of 50. AI continuous: a single invocation of the agent, or 24 hours of watching, or one result delivered. Same brand promise everywhere: the user always gets to feel what the microapp does before being asked to pay.

The word matters. Trial implies the user is borrowing time on something they'll have to pay for soon. Taste implies the user is checking whether this is the right fit — open-ended in time, bounded in scope, no built-in deadline. A non-member can take the taste of a continuous service today, ignore it for six months, come back next year and take the taste again. Nothing expires. Only the scope is bounded.

The transferable why: the difference between trust and friction is whether the user has experienced your product before you ask them for money. Trials gate the experience to time — and the time pressure becomes the brand's first impression. Paywalls gate the experience to nothing — the user has to take the brand on faith. Tastes gate to scope — the user gets the real thing in a smaller dose. The user who upgrades from a taste already knows what they're paying for because they've felt it.

Locked 2026-05-18 · every microapp has a taste · scope-limited, not time-limited


One last category matters as much as the four quadrants: what's explicitly NOT a microapp.

The platform with twelve features. The dashboard with seven tabs. The "comprehensive solution for X" with onboarding, tutorials, and a welcome modal. The product that needs a tutorial to use. The product that has its own subscription separate from Microapp's. The product that requires a free trial to evaluate. Any of these would dilute the brand into the shape it's explicitly refusing.

The line is drawn by three rules from the brand chapter and the values chapter, applied as a filter at the spec stage:

One — one purpose. If the spec describes more than one job, it's two microapps, not one. If it's hard to describe in one sentence, the spec isn't done. Two — thirty-second test. A first-time visitor must be able to use the microapp in thirty seconds without documentation. If it needs a tutorial, the design isn't done. Three — member-funded or ad-supported, no third path. No standalone subscriptions, no per-tool pricing, no in-tool upsells. The microapp is part of the Microapp catalogue or it isn't.

Three rules. Every microapp passes all three.

The transferable why: what your brand explicitly refuses to build is more load-bearing than what it builds. The shipped catalogue tells the brand's affirmative story; the refused specs tell the brand's discipline. A brand that can't articulate what it won't ship will drift into whatever the loudest customer asks for. Pick the no-list early; reread it at every spec review; let the no-list be the part of the brand that scales.

Locked 2026-05-18 · three filters at the spec stage · one purpose / 30-second / no third path

That's the microapp. One purpose, any runtime, four quadrants the catalogue grows into, three filters at the spec stage, one universal taste the user gets before being asked to pay. Every chapter downstream of this one — the model, the engines, the agent OS — runs against the unit defined here.