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 · in continuous production since 2018
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.
Problems that change the architecture.
Four kinds of problems we've built for — each with evidence you can inspect.
Scale & concurrency
When participation changes the problem.
Systems that must keep working as participation grows.
10,000 writes with the remote database stopped. None lost.
See the measurements
Distributed systems
When client-server stops fitting.
Shared state across participants without requiring one central authority.
A bingo night running on phones in one hall — no server, no database.
See The Village Hall
Edge & local-first
When the device is part of the system.
Software that holds state and continues to work when the network does not.
Four ways to run another organization's code on a phone. 8/8 escape attempts closed.
See the measurements
Architecture & reliability
When the architecture itself is the question.
Build and measure competing approaches before committing to one.
We built the orthodox version too. It refuted 2 of the 4 assumptions it was meant to confirm.
See the comparison
Building something that does not fit the usual architecture?
Bring us the problem.