Software that outlives the app it was written for.
ncubo builds distributed systems across mobile clients, services, clusters, data centers and independent participants — and a domain technology of its own that keeps 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 deployment changed. The domain did not have to.
From mobile clients to clusters, data centers and peer-to-peer systems.
We build systems whose behavior must remain coherent across applications, services, machines and independent participants. Some systems coordinate through a stable center. Others distribute authority between servers, data centers or peers. We design for both.
Shared organizational state · Context-aware approvals · Privacy-preserving coordination · Event-driven operations
- Flutter
- iOS
- Android
- Web
- C#
- .NET
- Linux
- Microservices
- Actors
- PuppeteerDeveloped at ncubo
- Kubernetes
- Containers
- Clusters
- Server-to-server
- Multi-data-center
- Peer-to-peer
Central servers when appropriate · Peer-to-peer when required
- Kafka
- SQL
- Distributed databases
- Reporting
- Observability
Centralized when appropriate. Peer-to-peer when required. Coherent in either topology.
Puppeteer
Puppeteer emerged from our work on systems that must preserve identity, causality and authority across participants, machines and changing topologies.
It is now a reusable architecture for building shared, continuous and coordinated systems, with working demos that make the architectural differences inspectable.
Architecture that can be read, tested and challenged.
Puppeteer is developed through an ongoing research series published on Zenodo. The demos make those architectural claims executable.
- 9Published papers
- ZenodoPublic record
- OngoingResearch series
1 domain5 measured stagings6 clients0 domain edits
Read the record →The Puppeteer Papers Series · Álvaro Rivera · published on Zenodo
The argument is executable.
Each demo holds a single thing fixed and varies everything around it, end to end and inspectable. Nothing here is a claim you cannot go and check.
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.
Not the invoice. Not the values. Not the business outcome.
What changed was the architectural authority: who was allowed to validate, persist, transport and render the act.
Start a technical conversation.
Whether you are evaluating a capability, planning a distributed system or considering a technical partnership — we would like to understand what you are building.
Start a Conversation