The origin story
That's it. That's the origin. I wanted to play Battlestar Galactica with friends who moved away, and I figured "how hard could it be to build a multiplayer game server?" Turns out: brutally hard. Not the game logic itself -- that part was fun. The hard part was everything around it.
A board game needs shared state that every player can see. But it also needs hidden information -- your hand of cards, a secret loyalty, a face-down tile. It needs turn enforcement. It needs to survive a server restart halfway through a six-hour game. And every player needs to see updates the instant something changes.
So I did what every backend engineer does. I reached for the standard toolkit.
A database for state. A cache for performance. A message queue for delivery. A WebSocket server for push updates. Authorization middleware for privacy. A workflow engine for the long-running stuff. Six components, six failure modes, six things that don't compose cleanly.
I spent more time wiring infrastructure together than writing game logic. Cache invalidation bugs. Race conditions between the pub/sub layer and the database. Crash recovery that worked 90% of the time (which means it didn't work). Privacy checks scattered across middleware that nobody could reason about holistically.
And the code volume was obscene. For every line of "a player draws a card," there were ten lines of serialization, synchronization, and error handling. The game logic -- the part I actually cared about -- was drowning in plumbing.
At some point I stopped fighting the architecture and asked a different question. What if the backend wasn't a collection of services? What if it was just... a document? A document that contains its own state, its own logic, its own privacy rules. A document that sleeps on disk when nobody's around and wakes up when a message arrives.
That's the core idea behind Adama. A living document. Every document is a tiny virtual machine. It processes messages sequentially on a single thread -- no concurrency bugs. It persists every state change through a write-ahead log -- no crash recovery to build. It computes minimal JSON diffs and pushes them to connected clients -- no cache to invalidate. And privacy? That's a language feature. The compiler rejects code that leaks private data before it ever runs.
One component. One deployment. One thing to reason about.
A sleeping document costs nothing. It sits on disk, taking up a few kilobytes, until someone connects. A hundred thousand game rooms can live on a single machine if most of them are idle. Storage for 100KB of game state runs about three cents. Forever. At S3 prices.
Compare that to running six services 24/7, each with its own scaling story, its own monitoring, its own on-call rotation. I've done the enterprise thing. I know what that costs in dollars and in sanity.
The thing about building for the hardest case is that everything easier falls out naturally. Board games need shared state with hidden information, turn enforcement, durable state machines, and real-time sync. Once you have that, collaborative tools are almost trivial. Approval workflows are just state machines that block for human input. Chat rooms are documents with an append-only table and per-user privacy views. Dashboards are reactive formulas over live data -- like a spreadsheet that pushes updates instead of waiting for you to hit refresh.
Even AI agents fit the model. An agent is just a session inside a document -- persistent conversation history, mutable state, tool access, all participating in the same transaction and durability guarantees. The compiler enforces token budgets. The runtime handles crash recovery. You don't bolt on an AI framework; you declare an agent like you declare a record.
Adama isn't for everything. If you're building a simple CRUD app, a traditional database is simpler and you should use it. If you need heavy computation, offload that to an external service. Documents are sized in kilobytes to low megabytes, not gigabytes -- this isn't a big data tool. And it's event-driven, not tick-based, so 60Hz physics simulations aren't the sweet spot.
But if your application has state that multiple people see differently, changes that need to sync in real time, logic that needs to survive infrastructure failures, or workflows that block for hours or days waiting on humans -- that's where the six-component architecture falls apart and a living document just works.
I've been working on Adama since 2020. It started as a game server and turned into a programming language, a runtime, a storage engine, a networking protocol, and a reactive HTML framework. That's probably too much for one person to build. I know that. But at core, I love the idea that you can write a text file, deploy it, and have a backend that handles persistence, real-time sync, privacy, and durable workflows without stitching together half a dozen services.
That idea keeps pulling me forward. The board game thing worked. Then the collaborative tools worked. Then workflows. Then AI agents. Each time I think I've hit the limit of the model, it stretches a little further. And every time I go back to a "normal" backend stack, I remember why I started this in the first place.
The infrastructure shouldn't be harder than the product. That's the whole argument.