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.
In 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.
We start somewhere else.
We write programs where the thing is what it did.
That model is Puppeteer.
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.
Replay them anywhere and the same history produces the same answer.
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.
- Authentication server
- Database
- Database backups
- API gateway
- Queues
- Infrastructure dashboard
- Central record store
- Always-online dependency
- The program
- The history
- The device
No central database
A hundred thousand customers don't have to become a hundred thousand rows in one place.
No nCubo server in the middle
An institution can give someone their history without giving nCubo a copy.
No always-online dependency
The program and its history can already be together on the device.
No infrastructure that grows simply because another person joined
Their device can do the work.
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.
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 demoIs this actually different from the conventional way?
The Same Invoice, Twice
The same invoice built both ways. Side by side. Executable.
Compare themWhat happens when execution stops halfway?
Unacknowledged
Interrupt the work. Then see what the subject knows.
Run it
Ten demos. Ten papers. One model being challenged from different directions.
Puppeteer isn't a prototype.
It is underneath what we build.
Mymi
Your information.Your device.Your choice.
Mymi is a person's own copy of what the places they deal with know about them. A laboratory. A supermarket. A dealership. A city hall.
Each institution hands over its own records. Those records live on the person's device. An AI assistant can ask only the questions that person has enabled.
Same substrate, different problems
Mymi can carry years of a person's records. The Village Hall carries ninety minutes of a bingo game.
One deals with institutions, personal history and AI. The other starts from a code printed on paper and runs between three phones in a room. One may live for years; the other is finished before the night is over.
Neither needs a server. That is not because they are similar products. It is because they are built on the same substrate.
Different problems. Same Puppeteer.
Numbers we can reproduce.
Real runs. Real devices. Dates included.
439 ms
First answer
vs 4,153 ms conventional
A54 · Sep 2026
100–250 KB
Another institution
vs 12 MB conventional
Xiaomi + A54 · Sep 2026
3,222,336
Same history. Same answer.
desktop · phone · WebAssembly
Sep 2026
Airplane mode
Answered on device
no network for the answer
iPhone 17 Pro · Sep 2026
View the full measurements
Full measurements
Device, date and comparison for every claim.
| 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 on all three | Desktop + phone + WebAssembly · 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 |
Every result above came from something running.
See the experimentsIt is not a storage decision.
The absence of a database can look like a storage decision. It isn't.
A database exists to put something back together. Take a subject apart into rows and columns and, whenever you need it whole again, reconstruct it from those pieces.
Puppeteer starts from a different premise. A subject is the program of what it did: its own actions, in order, with their consequences.
There is nothing to reconstruct from rows because the subject was never reduced to rows in the first place.
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.
They are its verbs.
- 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.
The Puppet is not a record whose current state is the thing and whose history merely explains how it got there. Its acts are part of what the Puppet is.
Which is why the same Puppet, given the same history and asked the same question on a laptop, on a phone and inside a WebAssembly sandbox, returns the same answer. Not three answers that happen to agree.
The same subject.The same history.The same answer.
We expect this to be checked.
Puppeteer is not documented only through product pages and blog posts. The argument behind it has been published across ten papers by the architect who built it.
The papers include the conditions that would prove the model wrong. They are deposited with DOIs.
That distinction matters. A software company can write a page saying its architecture works. We built the demonstrations, measured the results, published the reasoning, and made the argument inspectable.
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.
Go deeper into the substrate
The model in full: subjects with identity, the contract between the parts, and what continuity is defined against.
Meet PuppeteerRun something
See the demonstrations and challenge the claims yourself.
Explore the demosSee it as a product
See what this model looks like when it becomes something people actually use.
Meet MymiRead the argument
Ten papers, published with DOIs.
Read the Puppeteer papersAudit your own assumptions
Why It Is There is a way of looking at every layer in a stack and asking whether it would still have a job if the model underneath worked differently.
Audit the stack