A backend where you never need migrations or auth code — MonsterWriter

A backend where you never need migrations or auth code<br>How building a writing app led to building a Firebase alternative with a different idea about authorization<br>The goal: a backend you never have to change<br>No code changes when you add a feature. No database migrations when your data model evolves. No authorization rules deployed to the server. If you can build a backend like that, you have something genuinely new.<br>The tool I built to get there is called LinkedRecords — an open-source (MIT), generic backend-as-a-service for single-page applications, in the same space as Firebase or Convex, but self-hostable. The core difference is the authorization model: instead of writing permission rules in backend code, you assert them as facts — the same triple-store mechanism you use to query data. Your schema, your relationships, your access control: all stored as data the backend already knows how to enforce.<br>Here's how I got there.

2017: An itch that wouldn't go away<br>I was writing large architecture documents at work, using Google Docs for it. It worked — until the documents got big. Then it slowed to a crawl. And for technical writing, it was constantly in your way: no citation management, no table captions, no cross-references, formatting that fought you every time you inserted an image.<br>But what actually kept me awake at night wasn't the missing features. It was the real-time collaboration. Multiple cursors. Instant sync. No conflicts. You could see exactly who was writing where. How did they build that?<br>I'd actually tried to tackle something similar back in 2007 — a CMS usingcontenteditable— and failed. But now I had a clearer question: if I skip the page layout entirely (the part that makes Google Docs complex), and just let the browser handle rendering, how hard would it actually be to build the collaboration part?

Operational Transformation and a dangerous question<br>The algorithm behind Google Docs is called Operational Transformation (OT). In 2017 it was hard to find good documentation about it — one guy who'd worked on Google Wave had written it up, and that was basically it.<br>OT has two halves: a frontend part and a backend part. The backend part is opinionated — it needs to store data, manage change history, and broadcast updates. And that got me thinking: what if I built the most generic version of this backend I possibly could? Something reusable across any app I'd ever want to build?<br>I care a lot about zero-cost abstractions — the idea that you can generalize something without adding layers or overhead, sometimes just by renaming it to something more universal. That principle became the guiding constraint.

2018: LinkedRecords v1 — almost useful<br>The first version was a key-value store with streaming changes. You create an "attribute" — a piece of data, which could be long text, JSON, or a file — get back an ID, and subscribe to changes from any browser. The API looked like this:<br>const doc = await lr.Attribute.createLongText('initial content');

doc.id // → store this, retrieve the document later

doc.set('new content');<br>doc.change(/* a delta — e.g. "insert D at position 5374" */);

doc.subscribe((delta) => {<br>// remote update arrived — apply to editor<br>})<br>It worked for collaboration. But it was missing two things that made it useless for building real apps: no authentication/authorization, and no query language. You could only access data if you already knew its ID. Not practical.<br>So I made a pragmatic call: go build the editor first. Come back and fix LinkedRecords later.

2018–2023: Five years building the editor<br>MonsterWriter is the app I wished had existed — Microsoft Word rebuilt for students and researchers: citations, LaTeX export, cross-references, distraction-free writing, no page layout getting in your way.<br>Turns out contenteditable is a nightmare. Different browsers produce different HTML from the same input. Syncing remote changes means you have to save and restore the cursor position before applying each delta, or the user's cursor just vanishes. One content editable field per section (rather than one giant one) helps with performance. None of this is obvious until you're deep in it.<br>The GitHub history shows a long quiet stretch from 2017 through 2022. MonsterWriter is a real product now — people pay for it, students write their theses with it. But all along it was running on a backend I kept having to touch, which violated the whole original point.

The real differentiator isn't collaboration<br>When I came back to LinkedRecords, I had to be honest about something: the collaboration feature wasn't the main value anymore. CRDTs (conflict-free replicated data types) have become the go-to for this now — nobody would pick OT as their first choice today. The technology moved on.<br>What makes LinkedRecords different from Firebase, Supabase, or Pocketbase isn't real-time sync. It's the authorization system — and the fact that...