Senior Distributed Systems Engineer — Local-First Sync & CRDTs (Founding Role)

We're hiring a Senior Distributed Systems Engineer to design and build the core of our platform: a local-first sync engine in which every node keeps a complete, live copy of its data, operates fully while disconnected, and reconciles cleanly on reconnect — no lost writes, no manual conflict resolution.

This is a founding seat. You'll own the convergent data model, the replication protocol, and the correctness guarantees end to end, and define the interface the rest of the product is built on. It's the load-bearing layer of the system.

• Design and implement the convergent data model (CRDTs) — merge semantics that converge deterministically after arbitrary partition.
• Build the append-only operation log (event sourcing) underpinning sync, audit, and recovery.
• Implement causality and ordering — hybrid logical clocks across nodes that can't trust wall clocks or constant connectivity.
• Design the hub↔edge sync protocol — efficient reconciliation and anti-entropy that converges fast after long partitions and stays cheap on constrained links.
• Deliver correctness as an artifact — a test suite proving convergence under partition, concurrent edits, and node failure.
• Define and document the core's interface (API) that the product team builds against, and support their integration.
• Set the engineering standards for the core: architecture decisions, documentation, and knowledge transfer.

Skills

• Deep, hands-on experience with CRDTs or equivalent convergent replication — you've implemented, extended, or meaningfully contributed to conflict-free replicated data types, operational transformation, or a production sync engine. Library authorship or internals work, not only library use.
• Distributed-systems fundamentals in practice: eventual/causal consistency, logical and hybrid logical clocks, vector clocks, idempotency, partition tolerance — used in real systems, not just read about.
• Event sourcing / append-only log architectures in production.
• Sync or replication protocol design — hub-spoke, peer-to-peer, or anti-entropy/gossip.
• A correctness mindset: property-based testing, simulation/chaos testing of distributed behavior, or Jepsen-style verification. You treat "it converges" as something you demonstrate, not assume.
• Senior engineering judgment — you've owned a hard technical core before and can make irreversible architecture decisions carefully.

Who should NOT apply

We respect your time, so we'll be unusually direct. We have reviewed hundreds of applications for this role, and nearly all came from strong engineers in the wrong specialty. Please do not apply if the following describes you — not because your skills lack value, but because this specific seat is not your seat:

• Full-stack and web application developers. React/Angular/Node/Django/.NET/Laravel, building web apps, dashboards, APIs, and CRUD systems — even at a senior level, even with "distributed microservices" on your CV. This role has no front-end and no product surface. (We do hire product engineers separately — this posting is not that role.)
• Kafka / event-streaming / data engineers. If your "distributed systems" experience is Kafka, Spark, RabbitMQ, Airflow, ETL, or event-driven microservices — that is data movement at scale, a genuinely different discipline from convergent replication under partition. This is the single most common mismatch we see.
• DevOps, SRE, cloud, and IT-infrastructure engineers. Kubernetes, AWS/Azure, CI/CD, monitoring, Active Directory, networking, system administration, technical support. You operate and scale systems; this role builds database-grade internals. Different craft entirely.
• Mobile or desktop developers whose "offline" means local storage. An app with a SQLite/Realm/IndexedDB cache that uploads when back online is offline capability — the consumer side of sync. This role builds the engine: merge semantics, causality, convergence proofs. If you've only ever synced through a library or a backend-as-a-service, that's use, not internals.
• Engineers whose CRDT exposure is having imported Yjs/Automerge into a project. Using a CRDT library well is good engineering — but this role is for someone who could have written a meaningful part of one. If you can't explain how a CRDT achieves convergence without a central authority, don't apply yet.
• AI/ML engineers and data scientists. Different field. We may hire for analytics later; this is not that role.
• Junior and mid-level engineers, students, and recent graduates — regardless of talent. This is a load-bearing founding seat whose failure mode is silent data corruption in critical infrastructure. It requires senior judgment earned on production distributed systems. There is no "grow into it" path for this particular role.
• Generalists planning to learn this on the job. We're not hiring potential for this seat; we're hiring someone who has already done convergent replication for real. If the two-nodes question above didn't spark a concrete answer, this isn't the role to stretch into.