ian.schuepbach.work

my mom's budget is a markdown file

My mom does her budget on a spinning wheel. Glass cards, a dial of categories, and when she taps something, the change lands as a plain line of text in a file called the-numbers.md in her notes vault. The wheel renders itself from whatever is in that file and writes her taps back into it. She works the wheel, not the file -- the markdown underneath isn't something she deals with. And if the wheel disappeared tomorrow, her budget would still be sitting there, readable, in a format that will open in 2050.

Nobody designed that interface in Figma. It exists because her whole laptop got wrapped around her notes, with a contract I wrote for how its pages are allowed to behave.

01the setup

My mom's laptop is wrapped into a pseudo-OS around an Obsidian vault. Her front door is a single HTML page: one-line header, a clock, a morning brief that's just a rendered markdown file, a jot box that appends whatever she types into her daily note, a daily tip pulled from a tips.md file with about 40 tips in it, and so forth. Every piece of working data on that page lives in vault files. The page itself is disposable -- I can throw it away and have an agent build a better one, and nothing she cares about is at risk, because the page never held anything... it just showed it.

The rule I ended up writing down: files stay the substrate, surfaces multiply.

There's a trust angle here that took me a while to say out loud. If she's going to rely on these pages, they can't be baked exports. They have to be live, and she has to be able to trust that they always will be -- a page you have to worry about is a page you quietly stop using. So there's an actual contract: the page reads on open and on return, writes go through one narrow protocol with a hash check so a page never silently overwrites what it didn't read, and polling loops are banned outright (one 20-second poll loop once wedged her sync client for about 36 hours, which is how that became law).

02headings are the schema

The same pattern runs my kitchen. We cook for a household of 6-8, family-style -- a staple grain plus shared dishes, Sunday batch prep, three roles in the kitchen. The whole week's plan is one markdown file, FOOD-OF-THE-WEEK.md, and the heading levels are the schema. An H2 is a meal. Its workload badge rides in an H5, and whoever's playing sous chef that night gets their briefing from the H6 underneath. H4 fields become grouped info cards, H3 sections become color-coded instruction blocks for each phase of the night. A position-based parser reads it, Astro renders it, and git push deploys a full site -- grocery lists with checkboxes that persist per week, printable recipes, archive permalinks -- live in 2-3 minutes.

I write a text file. My family gets a website. The repo is hundreds of commits deep at this point, dinner actually runs on this thing.

Once you've done this twice, you notice the same shape everywhere. My mom worked through a 43-question budget worksheet as an interactive page, and her answers materialized as a markdown file (worksheets get put away when they're full). The page was temporary, the file is what she keeps. Most software is built the other way around -- the interface is permanent and your data is trapped inside it.

03the document answers back

The newest version of this goes further. In our vault there's a file format where you type @handle at an agent inside a plain markdown document, and the answer streams into the document at your caret, paced like a collaborator typing, 34 characters a second. The file stays pure markdown the whole time -- an agent reading it needs no special parser, and neither do you. I shipped a small public distillation of this, mention-watcher: a 193-line daemon that makes any markdown file a conversation surface. Type @claude in your notes and the answer arrives in place.

So a file can be plain markdown, or markdown with some live blocks in it, or the source of a whole rendered site, and it takes on as much UI as it needs -- nobody picks a format upfront. The plumbing in the middle is where all the time went, honestly: read-on-open, the write protocol, the hash check, and so forth.

04what a frontend is

A frontend is a view an agent can mint, on demand, from a substrate you own -- and the substrate is plain text. Treating the interface as the precious hand-built thing made sense when humans had to build every screen. When a screen costs one overnight agent run against a contract, you stop treating screens as precious. You keep the file.

I keep coming back to a dial-up analogy. Twenty years from now I think I'll be saying: when I was your age we had APPS -- you went to a store, downloaded Gmail, had a password. And some kid will look at me sideways, because from where they sit, software was always just a thing that showed up around whatever you were doing. Everybody makes their own. Like my mom does with her budget wheel, like my dad does with his schedule. I don't know exactly what the tooling looks like when everyone lives this way... my house already does, so I guess we're the beta.