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.
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.
Application owns the flow
One application flow coordinates domain behavior, authorization, persistence and response.
Domain owns the act
The Puppet decides the validity and consequences of the domain act. Infrastructure remains at the boundary.
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.
Projects end.
Domains continue.
ncubo is organized around reusable domain assets rather than isolated deliveries.
Every implementation adds knowledge, architecture and validated technology to the same underlying capability. The next system does not start from zero.
Each delivery serves the present. Each domain strengthens the future.
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 — the same architecture the comparison above puts side by side with a conventional implementation.
The Puppeteer Papers Series by Álvaro Rivera — 8 papers published on Zenodo. The demos enact what these describe.
- Anti-porous architectureFOUNDATIONS · ARCHITECTURE
- Program–value separabilityPROGRAM · VALUE
- Reactions and the partitionCAUSALITY · CONSISTENCY
- Continuity across actorsPARTICIPANTS · CONTINUITY
- Infrastructure as symptomPERSISTENCE · INFRASTRUCTURE
- The journal as substrateREPLAY · SUBSTRATE
- After the substrateINFRASTRUCTURE · DEPLOYMENT
- Inference without authorityAUTHORITY · OUTPUT
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.
- 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
Each demo holds one thing fixed and varies everything around it.
Five cases in coordination; a world interpreted differently for each participant; one shared event staged four ways; and a single domain moved across runtimes and clients.
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