Software with no server.No database.No cloud.
Everyone builds a cloud and puts an app on top of it.
We build the software differently — until some of the infrastructure has no job left.
Puppeteer has been in continuous production since 2018.
The interesting part isn't what we removed. It's why it wasn't needed.
Moving software out of a datacenter is not the interesting part. The interesting part is why it can leave in the first place.
Most software starts with records. A customer is a row. An invoice is a row. An account is a row. Programs keep those rows correct, databases store them, servers protect them, APIs expose them, and infrastructure keeps the whole thing alive.
And nobody was asked
The same total — ₡3,222,336 across 87 purchases — came back on a desktop, on a phone and in a browser. Each one read its own journal and asked nothing of anyone: no server was holding the answer, and none was consulted to produce it.
- Records
- Database
- Server
- API
- Cloud
Software where the subject carries its own history.
Puppeteer is the substrate underneath the way nCubo builds software.
Instead of storing a subject as pieces of state that have to be reconstructed later, Puppeteer preserves what that subject did. The operations belong to the subject. They travel with it.
That one change has consequences. Big ones.
When the model changes.
A normal system of this size comes with infrastructure whose job is to keep centralised state available, correct and safe. Change the model underneath and some of those jobs stop existing.
No longer required
- No central database
- No nCubo server in the middle
- No always-online dependency
- No infrastructure that grows simply because another person joined
What becomes possible
- History can move with the subject
- Institutions can hand history over directly
- The device can do the work
- Scale no longer has to follow user count
We didn't replace these layers with cheaper versions.We changed the model underneath them.
This does not mean the rest of the world has no servers: an institution still operates its own systems, and that is where its records come from. What is not there is a system of ours in the middle. Nothing of yours reaches an nCubo database, because there isn't one waiting for it.
It is not a claim. Run it.
Every important claim on this page has something behind it that can be opened, executed or inspected. We built the uncomfortable cases on purpose.
- Runnable proof
Without a server, how do devices agree?
The Village Hall
Three phones. A QR code printed on paper. A full evening of bingo. One phone dies and the hall carries on. No server, no database, 432 tests green.
Run the demo - Architectural comparison
Is this actually different from the conventional way?
The Same Invoice, Twice
The same invoice built both ways. Side by side. Executable.
Compare them - Causality test
What happens when execution stops halfway?
Unacknowledged
Interrupt the work. Then see what the subject knows.
Run it
Executable evidence. Published arguments. One model challenged from different directions.
Numbers we can reproduce.
Every number below came from one of the runs above. Real devices, dates included.
Watch them happen
One domain, staged across a console, browsers, an automated player and an emulated microcontroller. Twelve host projects, one directory of rules, and the diff that proves it did not change.
The remote database is stopped mid-run, the writes continue, and it is brought back. What waited during the outage was not a list of messages to be sent — which is why the replica rebuilt afterwards reaches the same state and not a similar one.
Full measurements
| What | Result | Measured on |
|---|---|---|
| First answer | 439 ms vs 4,153 ms | A54 · Sep 16–17 |
| Another institution | 100–250 KB vs 12 MB | Xiaomi + A54 · Sep 11–16 |
| Memory per institution | 9 MB vs 42 MB | Xiaomi + A54 · Sep 11–16 |
| Five institutions | 151–164 MB vs 238 MB | A54 · Sep 16–17 |
| Same history, three machines | ₡3,222,336 across 87 purchases, on all three | Desktop + phone + browser · Sep 4 & 16 |
| Recorded event | 33–97 bytes vs 118–910 bytes | Paper 5 |
| Offline AI answer | Answered in airplane mode | iPhone 17 Pro · Sep 17 |
| Offline writes, then reconnect | 10,000 queued, drained at 296/s, 20,999 on both sides | MySQL + SQL Server · Jul 13 |
Puppeteer isn't a prototype.
The same substrate is already inside a real product.
Mymi
Your information.Your device.Your choice.
That is data sovereignty as an architecture rather than a policy: there is no copy of your records on our side to govern, to lose, or to be asked for.
- Your records stay with you.
- Institutions hand them over directly.
- Your AI asks only what you allow.
Same substrate, different problems
Mymi can carry years of a person's records. The Village Hall carries ninety minutes of a bingo game.
Neither needs a server. That is not because they are similar products.
Different problems. Same Puppeteer.
It is not a storage decision.
The substrate declares two dependencies: a build-time analyzer and a hashing library.
Every storage type ends in one of two words:FileSystemInMemory
There is no seam where a database would go. The whole engine is about a megabyte.
For the technically curious
A Puppet is an Actor with CQRS + Event Sourcing.
But its journal records something different.
In conventional Event Sourcing, the journal preserves events describing what happened to the subject. A Puppet's journal preserves the acts performed by the subject itself.
- Events about the Actor
- Changes to its state
- Acts performed by the Actor
The journal is not a history of state.It is a history of acts.
The difference isn't just architectural. It's ontological.
A Puppet is not a record whose state is the thing and whose history merely explains how it got there. Its acts are part of what it is. So the same Puppet, given the same history, returns the same answer on a laptop, on a phone and in a browser — not three answers that happen to agree.
The same subject.The same history.The same answer.
We expect this to be checked.
A software company can write a page saying its architecture works. The argument behind Puppeteer has been published instead, by the architect who built it — with the conditions that would prove it wrong.
- Published
- 10 papers
- Falsifiable
- Conditions that could prove the model wrong
We don't just use architectures. We research new ones.
Puppeteer is one answer. Mymi is one product built from it. The demos try to break it. The papers make the argument inspectable.
What the demos ask
Questions about whether the architecture actually works:
- Can this work in practice?
- Can it survive failure?
- Can it cross machines, clients and topologies?
What the papers ask
Questions about the model itself:
- What does this imply?
- Where does the model fail?
- What assumptions does it challenge?
- What could disprove it?