A backend where you never need migrations or auth code

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.

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.

Here's how I got there.

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.

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?

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?

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.

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?

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.

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:

const doc = await lr.Attribute.createLongText('initial content');

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

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

doc.subscribe((delta) => {
  // remote update arrived — apply to editor
})

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.

So I made a pragmatic call: go build the editor first. Come back and fix LinkedRecords later.

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.

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.

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.

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.

What makes LinkedRecords different from Firebase, Supabase, or Pocketbase isn't real-time sync. It's the authorization system — and the fact that it's expressed as data, not code.

For the query language and authorization model, I remembered something from a university course on Semantic Interoperability: the Resource Description Framework (RDF). A triple store — every fact in the database is three things: subject, predicate, object. It was briefly called "Web 3.0" in academia before the crypto crowd adopted that term.

Nobody uses RDF in web development. But the model is clean. I didn't want to use the full SPARQL stack — that felt like overkill. What I needed was a Postgres table with three columns and some pattern matching. I called my implementation "Facts" instead of triples.

You describe what an attribute is — and who can access it — by attaching facts to it:

// Create a document and classify it
await lr.Attribute.createLongText('task content', [
  ['$it', 'isA', 'Todo']
]);

// Query all todos
const todos = lr.Attribute.find([
  ['$it', 'isA', 'Todo']
]);

// Transitive query: finds Biographies, Autobiographies, etc.
const allBooks = lr.Attribute.find([
  ['$it', 'isA*', 'Book']
]);

// Compound query in one request
const { books, bios } = await lr.Attribute.findAll({
  books: [['$it', 'isA*', 'Book'], ['$it', 'is', '$not(deleted)']],
  bios:  [['$it', 'isA*', 'Biography'], ['$it', 'is', '$not(deleted)']],
});

Authorization works through the same facts. Instead of writing permission rules in backend code, you assert them as data. LinkedRecords defines a small set of built-in permission predicates —$isAccountableFor,$isHostOf,$isMemberOf,$canRead, and a few others — and enforces them at the database level. You can model organizations, teams, roles, and sharing patterns purely through facts, with no custom backend code.

Think of it like giving users a very constrained SQL client. Within the rules the system enforces, they can query and modify data. If someone misuses their permissions, they can only harm their own data.

The longer-term vision is something I call Bring Your Own Backend.

Most SaaS sits somewhere between two extremes: PaaS (you manage your app and data, they manage the infrastructure) and SaaS (they manage everything, including your data). The gap in between — "I love the app, but I don't trust them with your data" — has no good answer today.

MonsterWriter is a single-page application. The frontend is served frommonsterwriter.com — always the latest version. The plan is to let users point it at their own LinkedRecords instance. You pick who runs your backend. Your data never has to leave your own infrastructure. You still get app updates automatically. The backend only needs security patches — otherwise it stays stable.

This isn't live in MonsterWriter yet, but it's where this is heading.

If this sounds familiar, it's because it rhymes with something the local-first community has been working toward. Local-first software — popularized by the Ink & Switch essay and the rise of CRDTs — puts your data on your own device, making the cloud optional rather than mandatory. The philosophy is the same: you should own your data, and the app you use to access it should be a separate concern from where that data lives.

LinkedRecords doesn't go quite as far as local-first — your data lives on a server, not your device. But it occupies the same ideological territory: the app layer and the data layer are decoupled, and you control the latter. Think of it as local-first's pragmatic cousin — cloud-hosted, but on a cloud you choose and trust.

This feels increasingly important. Cloud sovereignty has moved from a niche compliance concern to a mainstream political one. European companies are rethinking their dependency on US-based SaaS providers. Governments are scrutinizing where citizen data lives. The US CLOUD Act means data held by American companies is reachable by American courts, regardless of which country's servers it sits on. Against that backdrop, "you love the app but you don't trust them with your data" isn't a theoretical user story anymore — it's an enterprise requirement, and increasingly a personal one too.

The architecture LinkedRecords enables — a stable, self-hostable backend that any SPA can point at — is a small but concrete step toward a web where switching who holds your data is as easy as changing a URL.

MonsterWriter is a real product with paying users. LinkedRecords is the backend running behind it — and until recently, nobody knew it existed. The GitHub repository was published just recently. The documentation went up the day before the first public talk about it.

It's been 8 years of evenings and weekends. The commit history starts January 2017, goes quiet for 5 years while the editor got built, and has been steadily active again since 2022. The core idea — a generic, zero-migration, schema-free backend where authorization is data — has stayed the same throughout.

If you're building a single-page application and you keep running into the same backend boilerplate — schema migrations, hardcoded auth rules, user management — LinkedRecords might be worth a look.

MonsterWriter started as a tool for students writing theses. But the underlying architecture points somewhere much bigger.

Think about what Notion did: it took the idea of a document editor and stretched it into a general-purpose collaboration workspace — pages, databases, wikis, project tracking, all in one place, all multiplayer. It's genuinely useful. Millions of teams run on it. But there's a catch that almost nobody thinks about until it matters: every document, every database row, every comment your team has ever written lives on Notion's servers, under Notion's terms, governed by Notion's jurisdiction.

The vision for MonsterWriter and LinkedRecords is to build toward that same kind of collaborative workspace — documents, structured data, real-time multiplayer, rich content — but with a fundamentally different answer to the question of who holds the data.

The answer LinkedRecords gives is: whoever you decide. Your company runs its own LinkedRecords instance. Your team's data stays in your data center, your cloud region, your jurisdiction. The application — the UI, the features, the product improvements — is delivered as a SPA from a server you don't have to trust. The two concerns are cleanly separated. You get the product without the lock-in.

Collaborating with someone from a different organization doesn't mean merging your data into a shared vendor's silo. It means two LinkedRecords instances exchanging facts with each other, while each organization retains full control of its own data. Like email — nobody thinks it's strange that Gmail and Outlook can send messages to each other, even though they're run by competitors. Collaboration apps could work the same way.

We're not there yet. The federation layer doesn't exist. MonsterWriter today is a writing tool, not a Notion replacement. But the data model, the authorization primitives, and the bring-your-own-backend architecture are being built with this in mind from the start — because retrofitting data sovereignty onto a platform that was never designed for it is much harder than building it in from day one.

It's an ambitious target for a solo side project. But sometimes the right architecture is obvious before the product is ready for it.