Your team and tools. One shared place.
Status: In build
Bring people, conversations and work into the same context.
Neighbourhood workshop
Plan the next workshop
Interactive example · changes stay on this page
Start with the tools your team needs.
Add more as your work grows.
Read the full project overview
This is an experiment on the layer: One is where people and teams actually operate: the shared shell, discovery, and composition surface that keeps apps and services coherent instead of scattered.
What it is
One is the reference operating surface of the ecosystem. It is the environment where modular business and coordination services run together with explicit trust and governance boundaries.
Like every Unifyhub product, One implements the shared contracts and can be replaced through them. What is mandatory is the contract; the control plane earns its place by being the best implementation of it.
The need it answers
People, teams, and organizations need a trustworthy way to run identity, coordination, and business capabilities as one coherent system, without stitching together disconnected tools, weak trust assumptions, and fragmented operations.
The problems behind that need:
Tool sprawl creates disconnected operations. Separate products for identity, messaging, accounting, and workflow drift apart: different identities, inconsistent permissions, duplicated state.
Trust depends on private promises. Users are asked to believe rules will not change arbitrarily, decisions will be recorded honestly, and access will be enforced consistently, while the system makes no strong commitment by design.
Early growth can bury product quality under noise. Open systems can maximize access before the product is ready for it.
Who it is for
Long-term, One is for anyone who wants a coherent, trustworthy platform for coordination, operations, and modular services:
individuals who want a unified environment instead of juggling disconnected tools
teams that need shared identity, access, workflows, and communication
organizations that need modular business capabilities such as workspace, accounting, inventory, and messaging
communities and networks that need both public participation and higher-trust internal coordination
node operators who want deployment and exposure control
technical builders who want to extend, adapt, or integrate the platform
Early stages may focus on a narrower core team and early member base, as a path to broad adoption.
Product shape
IAM provides the identity and authority foundation; the Portal provides the shared shell, discovery, and composition surface.
Domain capabilities stay modular, so a node runs only the services it actually needs.
Public and private exposure coexist, so discovery and filtering work without exposing the whole operating environment.
Constitutional, auditable rule design is part of the platform thesis, so the system can make strong promises about what can change and how.
Early community formation can be selective while the product matures, as a launch tactic with a stated end.
Deliberately deferred
While the operating core stabilizes, One defers:
polished self-serve onboarding on day one
convenience-first growth ahead of a stable operating core
unlimited early participation ahead of trust and governance foundations
a flat marketplace of unrelated apps
Each of these can grow later, on top of a core that already keeps its promises.