Inside VorxSync: what we're building for realtime and offline

VorxSync is a local-first data layer we're building - the same kind of engine we built for our own products and hardened in production before Vorx existed. The plan is that you won't ask for it, you won't be able to forget to add it, and you'll never write a line of it: it'll simply be how a Vorx app behaves. It isn't in the apps you build today. This post is about what it's designed to do, and why it's normally so hard to get.

Local writes, instant

In a VorxSync app, the data your screens read would live in a local database, with writes landing there first. Click, and the UI updates immediately - no spinner, no skeleton, no round-trip to a server to see your own edit. The change would flush to the server in the background, so your users never wait on the network to be shown something they just did.

That's not just an optimisation, it's an architecture. Most web apps ask a server for permission to show you your own data; a local-first app keeps the data with you and treats the server as the thing to reconcile with, not the thing to wait for.

Realtime, by default

Because every client would sync against the same engine, realtime becomes a consequence rather than a feature to bolt on. Open the same record in two tabs, or on two people's laptops, and edits would stream between them live - no socket code to write, no presence system to build. The generated app would get collaboration the way it gets a database: because it comes with the build.

Offline, working

Drop the connection and the app keeps going. Reads would come from the local store, writes would queue up, and when the network comes back the queued changes reconcile with the server automatically.

Why this doesn't normally exist

None of this is a secret. Local-first is well understood, widely admired, and rare - because sync engines are brutally hard to build: conflict resolution when two people edit the same field offline, ordering guarantees, offline queues that survive a crash, schema migration across devices that have been offline for different lengths of time. This is the category of engineering that eats specialist teams, which is why the apps that feel this way have mostly come from well-funded companies who could afford those teams.

That's the gap we're closing. We've spent years building and hardening a sync engine like this in production, for real customers who would have been rightly furious if it lost their data. The plan is that when Vorx generates your app, it generates it on that engine - schema, queries and sync wiring produced together, as one coherent thing.

What it will mean for what you build

Once this ships: your app should feel immediate from the first build, keep working when the wifi doesn't, and let two people work on the same thing without trampling each other - without you needing to know what a CRDT is, or that this problem existed at all.

It isn't live yet. We'll update this post - and the features page - the day it ships.