Disposable Micro-Apps

Sources#

How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development

Summary#

Thariq Shihipar's answer to the obvious objection against HTML plans: HTML isn't as easily editable as markdown, so what do you do when you want to change a complex table or a set of rules buried in an HTML artifact? You ask Claude to build a temporary, disposable user interface — a micro-app — just for editing that one specific part of the plan. Instead of editing the artifact by hand or grinding through chat, you generate the ideal tool for the edit and use it once.

"It's like this is not even personal software. This is like sub… it's like micro-software on top of micro-software."

The worked example#

Thariq's HTML implementation plan contained a set of decision rules for turning different CSV data types into visualizations. He felt the rules were "a bit arbitrary" and wanted to refine them — a tedious thing to do in prose or in raw HTML. The prompt:

I want to create an edible HTML artifact to help me define the decision rules...
I don't like the ones we have right now. Make this a custom UI that helps me with
structure but gives me flexibility. Design the ideal interface for this problem.

("edible" = editable — another harmless typo the model handled.) Claude returned a dedicated webpage: input fields, dropdowns, add/remove buttons, and a button to copy the final configuration back to the clipboard as markdown. Thariq edited the rules in a structured, visual way, got the output right, and brought the perfected data back into his main workflow.

Two design notes that make it work#

"Design the ideal interface for this problem." The human specifies the problem, not the widget set, and lets the model pick the interface — constraint plus latitude, the same prompting move as in HTML as the New Markdown.
Copy-back-to-markdown. The micro-app is a transient editing surface over durable text. This patches HTML's worst weakness (diffing/versioning) — the source of truth round-trips through markdown, while the rich UI exists only for the duration of the edit.

Why this is now rational: the abundance mindset#

Spinning up a single-use application to make one editing decision would be absurd under scarcity economics. It is rational under the Compute Allocator's abundance mindset: generation is cheap enough that throwaway tools are a sensible investment in your own process. "We can now afford to generate these throwaway tools to make our own process more efficient and enjoyable." This is Printing Press Software Democratization at the scale of a single task — software so cheap to produce that it becomes a disposable convenience, not a project.

Connections#

Narrow Wedge into a Legacy Market — a Google-Sheets-grade MVP is a disposable-app wedge into a legacy market
Design by Selection — the pattern one level deeper: Nate Parrott had Claude Design build him a bespoke video editor, then used that editor to make the Claude Design intro animation. Not a UI for editing a plan but an authoring tool for a medium the human has no skills in — generated so the human can work by direct manipulation in a domain where they can judge but not produce
Thariq Shihipar — originator of the micro-app workflow
Claude Code — the product used to generate the throwaway UIs on demand
HTML as the New Markdown — the plans these micro-apps edit; micro-apps answer its editability objection
Compute Allocator — the role/economics that make disposable tooling rational
Living Design System — the durable counterpart: a micro-app you keep and reuse as context
Printing Press Software Democratization — software cheap enough to be disposable
Harness Shrinkage as Models Improve — micro-apps are human-facing scaffolding (built per-task for the human), distinct from the model-facing harness that shrinks
Software 3.0 — micro-apps are Software-3.0-native: Karpathy's MenuGen "that app shouldn't exist" is the same logic — apps cheap enough to barely exist
Building Is Cheap, Arguing Is Expensive — throwaway built artifacts as the unit of decision; cheap building makes the disposable UI rational

Open Questions#

Where's the line between a disposable micro-app and tool sprawl? If every edit spawns a bespoke UI, does the workflow fragment?
Does the copy-back-to-markdown round-trip generalize beyond config-shaped data (rules, tables) to richer artifacts?

Resolved Questions#

Could these micro-apps be templated/reused rather than regenerated — and at what point does that defeat the "disposable" framing and turn into durable tooling? Answered: The HTML Artifact Lifecycle: Where Plan History Lives, and When Disposable Becomes Durable — the correct reuse unit is the generator, not the artifact: a recurring micro-app pattern becomes a skill that regenerates a fresh, fitted app each time, keeping disposable's per-task fit while gaining reuse's consistency (the measured systematization move — skills at 5.4%→26.6% of weekly-active users). An artifact itself graduates to durable only under recurrence + sync-pressure + audience (the design_system.html profile), at which point it inherits maintenance cost, sync cadence, and a seat under the artifact-sprawl bloat ceiling. The failure mode is the un-chosen middle — apps kept around unmaintained: sprawl plus rot with neither fit nor consistency. The discipline is binary: regenerate it, or maintain it; never merely keep it.

Derived#

Does the Human-Facing Harness (HTML Artifacts) Hit Its Own Bloat Ceiling? — micro-apps are the decomposition escape valve that softens the bloat ceiling, but tool sprawl is the axis the ceiling relocates onto
The HTML Artifact Lifecycle: Where Plan History Lives, and When Disposable Becomes Durable — the disposable-vs-durable graduation rule: reuse the generator (skill), regenerate the app; graduate artifacts only under recurrence, sync pressure, and audience

Sources#

How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development