Mere: The File Is the App
A workbook format where the file contains everything — screens, state, behavior, theme, data. Open it and it runs. Send it and it travels. No server, no account, no build step. And why that matters more than it sounds.
What Every App Format Gets Wrong
Every app you use today requires infrastructure you do not own. A server somebody is paying to keep running. An account that can be suspended. A build pipeline that needs maintenance. A runtime environment tied to a specific platform. The app does not belong to you — you are a tenant in someone else's system.
This is so normal it has stopped feeling like a constraint. It is just how software works. You accept the terms of service, create the account, trust the cloud provider, hope the company does not get acquired or shut down. The alternative — owning the software the way you own a document — seems technically impossible.
It is not. It just requires rethinking what an app format is for.
The File Model
Excel proved this model works thirty years ago. A spreadsheet is a single file that contains everything: data, formulas, layout, computed values. You send it to someone — via email, USB stick, Slack — and they have the same spreadsheet. No server. No account. No expiry. The file is the application.
Millions of people run entire businesses in .xlsx files. Not because Excel is sophisticated software architecture, but because the portability and sovereignty of the file format solve real problems that no amount of cloud infrastructure can match.
Mere applies that model to apps that are not spreadsheets. A .mp.html file is a complete, self-contained, executable artifact. It declares its own screens, state, behavior, theme, and data. Open it — it runs. Send it — the recipient has the same app.
| Every other app format | Mere |
|---|---|
| Requires a server to run | Runs in any browser, offline, forever |
| Requires an account to access | No account — the file is the access |
| Data lives on someone else's infrastructure | Data lives in the file, on your device |
| Sharing means sending a link | Sharing means sending the file |
| Breaks when the service shuts down | Works in ten years exactly as it does today |
What It Looks Like
Below is a live Mere workbook — running in your browser right now, inside this post. Type in the field. The heading updates instantly. Hit Reset. The state returns to its declared default. The entire app is a single .mp.html file.
Four Sigils. That's the Grammar.
The word sigil comes from the Latin sigillum — a seal or sign. In programming, sigils are prefix characters that carry semantic weight beyond their shape. Perl used them to mark variable types. Mere uses four to describe every possible relationship between an element and the workbook's state.
One-way binding from state. On a text element, displays the value. On a list container, iterates the array — one child per item.
<heading @title>Bidirectional sync between an input element and a state value. Input updates state; state updates the input.
<field ~email>Invokes a named action on click. Arguments follow after with. Actions are plain text — one statement per line.
<button !submit>AI compositor annotation. Describes what an element should become during generation. Ignored entirely at runtime.
<screen ?"Show inbox">Four characters. Every data relationship in any app is one of these four things: read from state, write to state, trigger an action, or annotate intent for a generator. The grammar is complete.
State, Actions, and Persistence
State is declared explicitly — named, typed, with a default value. Actions are plain text, one statement per line: set, clear, add-to, go-to. No JavaScript. No event handlers. No framework.
Add persist to any state value and it survives browser closes, written to OPFS with a localStorage fallback. One attribute. No boilerplate.
<workbook theme="proton-mail">
<state>
<value name="tasks" type="list" value="[]" persist />
<value name="new-task" type="text" value="" />
</state>
<computed>
<value name="task-count" from="tasks" op="count" />
</computed>
<actions>
<action name="add-task">
add-to tasks title @new-task
clear new-task
</action>
</actions>
<screen name="home">
<header>
<heading>Tasks</heading>
<badge @task-count></badge>
</header>
<field ~new-task placeholder="New task…"></field>
<button !add-task>Add</button>
<card-list @tasks>
<card><heading @item.title></heading></card>
</card-list>
</screen>
</workbook>26 Elements. No Escape Hatch.
Mere has 26 semantic elements. Not HTML — Mere elements. There is no passthrough to arbitrary HTML. The vocabulary is closed by design.
<heading> does not just mean “render text large.” It means “this is the primary label for this screen or card.” <badge> means “this is a count indicator — hide it when zero.” The elements carry meaning, not just appearance. The same semantics render differently across themes but mean the same thing everywhere.
The constraint is load-bearing. A bounded vocabulary means an AI generating a workbook has exactly one way to build a list, one way to show a count, one way to wire an input. No decision fatigue, no inconsistent output.
The AI Angle
The sigils, the 26 elements, the text-based action syntax — these are not for humans to memorize. They are a target language for generation.
When an AI generates a React component, it faces infinite choices: which hooks pattern, which state library, which CSS approach, which event model. That freedom produces inconsistent output. Generated JavaScript breaks in ways that are hard to catch before runtime.
Mere eliminates those choices. Every element has known rendering behavior. Every sigil has known semantics. Every action statement has known effects. The output is predictable in a way that generated HTML and CSS and JavaScript never is. A model can produce a valid workbook reliably — and mere check will tell you immediately if it did not.
AI is the builder. Mere is the medium. The file is the artifact.
The spec page on the docs site is documentation for the generator, not for the user. Describe what you want. A model produces a .mp.html file. Double-click. It runs. No deploy step. No publish step. The file is the share.
The Trust Layer
Local-first is not just a technical property. It is a social one.
When someone opens a mortgage calculator on a website, there is a background anxiety — is this sending my salary, my loan amount, my financial situation to a server somewhere? Most people cannot answer that question. They just accept it.
When someone opens mortgage-calculator.mp.html — a file on their machine — there is no such question. Files do not phone home. The app is the file. It is the same trust model people have had with documents for thirty years. Your parents understand files. They do not understand “the cloud.”
You send them budget-planner.mp.html. They open it. They type their numbers. Nothing leaves their computer. That is comprehensible in a way that “we anonymize your data” is not.
What You Can Build
Calculators are the ideal Mere use case — purely computational, personal data, shareable as tools, timeless. But the pattern generalizes to anything that benefits from sovereignty.
Mortgage calculator
Monthly payment, total interest, amortization
Bill splitter
Table of friends, items, running totals
Savings goal tracker
How long to reach $X at $Y/month
Expense tracker
Categories, persist, running totals
Recipe scaler
Adjust servings, ingredients recalculate
Gift budget
Who, what, how much — offline, private
Every one: one file, double-click, works offline, shareable, private. No sign-up prompt. No data leaving the device. No service to maintain.