The Tech Industry’s Biggest Regret: Abandoning Lotus Notes

You’ve been there. You spend weeks building what you think is a simple offline-first feature. You pick a popular sync framework, follow the docs, and it works in the demo. Then you hand it to a real user who goes underground, loses signal, and edits the same record on two devices. When they come back online, your app silently corrupts their data. You stare at the screen. Convergence is only a small part of sync. The difficult parts are durability and conflict resolution.

This is the pain that drove me to build Syncular. But as I dug deeper, I realized something uncomfortable: the industry didn’t just forget how to do offline-first — we actively unlearned it. We traded battle-tested architectures like Lotus Notes for shiny cloud APIs, believing that centralization would simplify everything. We were wrong.

Let me be blunt: the modern cloud-first approach is a regression, not an evolution. Lotus Notes, built in the 1980s, handled offline replication, conflict resolution, and eventual consistency before most of us were born. It wasn’t perfect, but it understood one thing we’ve forgotten: sync is a distributed systems problem, not a state management problem. The tech industry paid a very high price for that amnesia. Every time you refresh a web app to see new data, every time you lose your edits in a mobile app because you went offline, you’re paying that price.

I know what you’re thinking: “But CRDTs solve this!” They don’t. CRDTs are a beautiful mathematical solution for convergence, but convergence is the easy part. The real monsters are durability (making sure data doesn’t vanish when a device crashes mid-sync) and conflict resolution (deciding which version of a record matters when two users edit the same field while disconnected). CRDTs handle the latter with operational transforms, but they don’t guarantee durability. And they say nothing about the real-world mess of partial writes, network partitions, and user expectations.

Syncular isn’t a magic bullet. It’s a pragmatic answer to a problem that the industry has been pretending doesn’t exist. It uses a CRDT-inspired core written in Rust, but wraps it with a SQL interface and TypeScript bindings. The key insight? Treat sync as a database durability problem, not a state synchronization one. Write-ahead logs, transaction boundaries, and conflict versions — these are the building blocks of a system that doesn’t break when the network drops.

But here’s the twist: the hardest part wasn’t the code. It was convincing myself that building yet another offline-first tool wasn’t a waste of time. Because the market is flooded with half-baked solutions that promise “offline-first” but deliver “offline-first until it breaks.” The real problem isn’t technology — it’s that we’ve normalized fragile, always-online assumptions. We’ve built a generation of developers who think a 500 error means “try again later” instead of “your data is gone.”

So yes, I’m taking a side: offline-first isn’t a feature. It’s a philosophical stance about who owns your data. If you’re building an app that touches people’s lives — notes, health records, financial data — you owe it to them to respect the reality that networks fail. The cloud is not a promise. It’s a temporary convenience.

I’ll leave you with this: the next time you reach for a cloud API, ask yourself what happens when the internet goes down. If your answer is “it doesn’t matter,” you’re building for a world that doesn’t exist. The industry abandoned Lotus Notes because it was “old.” We’re now spending millions rediscovering what it already knew. Syncular is my attempt to stop that cycle. It’s not the answer — but it’s a start.