Software that outlives the app it was written for.
nCubo builds distributed systems across mobile clients, services, clusters, data centers and independent participants — and Puppeteer, a substrate of its own designed to keep them coherent when the deployment, the client or the topology changes.
Projects end.
Domains continue.
Every implementation should solve something useful now and strengthen the domain asset available to the next one.
- 1
- domain
- 5
- measured stagings
- 6
- clients
- 0
- domain edits
The client is not just a window into the system. It can be part of the system.
Most software keeps computation and state in a data center and reduces powerful devices to interfaces. We design systems that can use the capacity those devices already have.
- More participants can mean more capacity — not just more load.
- Capability can live where it makes sense.
The system can live where its participants live.
Different runtimes. One coherent architecture.
The same system can span devices, shared services, data centers and direct peer-to-peer coordination.
Replication · Replay · Multi-data-center · Kubernetes · Zero-downtime deployment · Red/Black deployment
Centralized when appropriate. Peer-to-peer when required. Coherent in either topology.
Once a system can live in many places, a harder question appears.
Who owns identity, state and authority when no single place owns the whole system?
We build distributed systems from software subjects with identity, authority and histories of their own.
Puppeteer is the substrate built to let those subjects execute concurrently across machines and changing topologies.
A substrate developed at nCubo
Architecture should survive scrutiny. So we make ours inspectable.
10papers
Identity, authority and causality — each paper building on the ones before it.
The Puppeteer Papers Series
One domain. Many stagings. No rewrite.
Zero domain edits was shared by the comparison baseline. The architectural difference was where outward obligations and reconstitution lived.
The argument is executable.
Each demo takes one architectural claim, builds it end to end and says what it does not establish.
The same invoice, built two ways.
A conventional .NET invoice flow, and the same domain enacted as a Puppeteer Puppet. Same products, same amounts, same invoice — different architectural center.
- 22→5Files in the domain
- 5→0I/O calls inside the flow
- 0Output formats in the domainConventional: web framework dependency
Counted in the repository. An existence proof that the separation is buildable — not a performance or cost evaluation.
When this is the problem, this is the work.
Four conditions we have built for, each with something on this site you can check.
When scale changes the problem
Systems that have to keep working as participation grows, without another layer of infrastructure to hold them together.
Ten thousand writes taken with the remote database stopped — none lost.
The measurementsWhen the phone is part of the system
Local-first architectures where the device holds state, answers questions and keeps working when the network does not.
Four ways to run another organisation's code on a phone, measured on real devices; eight of eight escape attempts closed.
Four ways, measuredWhen conventional client-server stops fitting
Peer-to-peer participants and shared state with no centre that everybody has to agree on.
A bingo night running on the phones in one hall — no server, no database.
The Village HallWhen the architecture itself is the question
Prototyping and measuring the alternatives before committing to one — including the one we did not want to win.
We built the orthodox version too, and published that it refuted two of the four things it was meant to confirm.
The comparisonBuilding something that does not fit the usual architecture?
Bring us the problem.