I rebuilt my business as a folder of markdown files

The failure: My first attempt collapsed under its own duplication

For years I ran the consultancy out of the usual sprawl. Client details in Google Docs, invoices in one place, project notes in another, and the context that mattered most - what a client cares about, why we picked a stack eighteen months ago - living almost entirely in my head.

So I built a knowledge base to fix it. It lasted about three months.

The problem was that I kept writing the same fact twice. A client's day rate went in their profile, then again in the project brief, then again in a pricing note. When the rate changed I'd update one and forget the others. By March I couldn't trust anything in there, so I stopped reading it, and once I stopped reading it there was no reason to keep it current.

That workspace is still sitting on my drive, archived and untouched. I keep it because the failure taught me the rule the replacement is built on: one canonical location per fact, and everything else points at it.

The rebuild: A router, not a database

What I use now is a folder of markdown files. Clients, projects, finance notes, brand tokens, and the step-by-step for anything I do more than twice. It opens in Obsidian when I want to read it as a human, and in Claude Code when I want to work on it.

The file that does the heavy lifting sits at the root. Claude reads it automatically at the start of every session, and it has two jobs. It declares what owns what, and it says when to go and read something else.

The ownership rule is blunt. My CMS owns invoices, tasks and published website content, because those need to live in a real database with real relationships. The vault owns everything else: context, decisions, the history of a client relationship. Neither one is allowed to copy from the other. If I want to know what a client owes me, the answer comes out of the CMS through its API, never out of a note I wrote in March.

The second job took me longer to get right. Instead of loading everything at once, the root file carries a table of conditions - read the brand tokens when the work is visual, read this client's memory file when the work is theirs, read the invoice procedure before touching an invoice. Loading four relevant files beats loading forty, and not only because it's faster. Anything permanently in context is something I have to keep permanently correct.

The unit of work: Skills, not habits

Sitting alongside the vault are thirteen skills. Each one is a markdown file describing a workflow in enough detail that it runs the same way every time, whether I'm the one asking or something else is.

Raising an invoice is a skill. So is onboarding a client, scaffolding a project repo, producing the weekly market intelligence report, generating the morning brief, and writing a post like this one.

They're files rather than habits because a file can hold a gotcha. My invoicing workflow contains a hard rule about never setting the invoice number by hand, because the CMS generates it and overriding it corrupts the sequence. I learned that once, painfully. Now it's written down where it matters, and I will never learn it again.

One of them runs without me. A phishing detector checks the previous hour of email against a list of tells and labels anything scoring two or more. It has no permission to delete, archive, move or reply. It flags, and I decide. I drew that boundary deliberately after nearly falling for a very good spoof myself a while back. Automation that acts on my inbox is a risk. Automation that points at things is a second pair of eyes.

The hardware: A touchscreen running the same workflows

There's a 1280×720 touchscreen on my desk running an Electron panel styled after the LCARS interfaces from Star Trek. The styling is pure indulgence. What it's wired into isn't.

The panel reads the vault's reports folder and renders whatever's in it - the day's brief, the weekly intelligence, the monthly finance summary. Its buttons fire the same skills I'd otherwise trigger by typing, through a headless call to Claude. None of the workflow logic is duplicated in the app. The app is a surface.

That's why the reports folder has a fixed format I treat as an API. Anything that reads it, the panel now and a voice layer later, can rely on the shape without me rewriting it every time I add a screen.

Speech is the layer after this one. Local transcription in, local synthesis out, and a router in the middle that handles obvious commands with pattern matching, sends ambiguous ones to a small fast model, and escalates the genuinely complex ones to a full session. Turning every recurring piece of work into a skill rather than a habit is what makes that possible at all, because a voice command needs something concrete to invoke.

The payoff: What I stopped having to say

The difference I notice most is what I no longer explain. A client's rate, their stack, the reason we ruled out a platform two years ago, the name of the person who actually signs things off - it's all there, and it loads itself when the work is theirs. Context stopped being something I supply and became something the system already holds.

That changes the shape of a request. "Invoice them for the migration work" now produces a drafted invoice in the CMS with the right number, the right rate and the right project attached, written back to the vault, in about a minute. The old version of that job was a browser tab, a rate lookup, and a reasonable chance of fumbling the number.

Then there's the work that arrives without being asked for. The morning brief is written before I sit down - today's calendar, anything overdue, what's sitting untriaged in the inbox, and the three things most worth my attention. The phishing scan runs hourly. The market intelligence report lands weekly. None of it waits on me remembering.

The compounding is the part I underestimated. Anything I do twice becomes a skill, so the second time is the last time I have to work out the order of operations. Onboarding a client used to be an afternoon of setting things up and forgetting one of them. It's now a single instruction with no missing steps at the end of it.

I run eleven clients with no admin support and no operations manager, and the reason that works is that the back office is a folder.

The trade-offs: What it actually costs

This isn't free, and I'd be selling you something if I pretended otherwise.

The discipline is real. Every time I'm tempted to drop a client detail into a project file because it's convenient, I have to go and put it in the client file instead. The rule works only if it holds every time, and I'm the one enforcing it.

It's also a system with one user. Everything in it assumes my judgement, my clients, my way of quoting work. Handing it to someone else would mean rewriting most of the skills, because a workflow file is a description of how one specific person works.

And it took months of evenings, mostly at the point where I was too tired for client work but not tired enough to stop. If your business already runs smoothly on tools you trust, none of this is urgent.

The bottom line: The AI is the least interesting part

What made the difference wasn't the model. It was deciding where facts live and refusing to break that rule.

The AI is what makes a folder of markdown files behave like software. It reads the router, follows the workflow, and does the work. But it's operating on a structure I'd have benefited from having anyway. Point a capable assistant at a messy set of notes and you get confident answers built on contradictions.

Every business already runs on an operating system. Most of them are undocumented, and living in one person's head.

Steve Lavine is a full-stack developer and founder of Lavine Web & AI Solutions, working with SMEs and startups across the UK. lavine.dev