Why Zanbase is one app, not ten

I am building Zanbase around a simple requirement: a team’s work should belong together. The conversation about a decision, the document that explains it, and the project that carries it out should live in the same workspace.

That requirement shapes more than the list of features. It shapes what we build underneath them. Zanbase is one workspace app, with chat, docs, tables and forms, projects, meetings, files, whiteboards, presentations and reels, Zanbase Agent, and automations. The point of putting them together is the relationship between the work in each.

Our main audience is growing teams of about 20 to 200 people. I want the person joining a project to spend their attention understanding the work. Reconstructing where the work lives should demand as little attention as possible.

Start with the work that crosses a boundary

Consider a team preparing a proposal. This is an example, not a customer story. The team needs a brief, a conversation about the brief, tasks for the deliverables, and a table of information used in the proposal.

The handoffs matter. A question in the conversation refers to a paragraph in the brief. A task needs the reasoning behind that paragraph. Someone joining later needs to follow those references without asking a colleague to reconstruct the decision.

In Zanbase, links and mentions connect work in the same workspace. A task can refer to the doc behind it. The relationship still needs to be made: the app does not automatically attach every relevant conversation, meeting, and file to a task. That distinction matters. We provide the shared place and the means to connect it; people still decide what belongs together.

One foundation, different kinds of work

A data model is the way software represents things and their relationships. Zanbase starts with resources: items such as a doc, a channel, a table, or a project, each with a place in a workspace’s tree.

A chat message belongs to its conversation. A task belongs to its project. They have different contents and different jobs, but they participate in the same workspace model. Saying that everything is data does not mean that a message and a table row are interchangeable. It means we do not build a separate workspace around each feature.

That gives shared behavior a home. Access, sharing, links, and mentions belong to the common foundation. A doc does not need an unrelated identity system just because its editor differs from a table. A project does not need a separate account for the person who already works in its workspace.

For a person using the app, the useful part is continuity. You can work with different kinds of content without treating each as a separate product with its own membership.

What truly unified means in practice

Permissions are part of that continuity. The app uses one resource access model across its kinds of content. Sharing a resource is a decision about who may use that work. Linking to it is a different decision: a reference does not grant someone access to its destination.

Search also has one place in the workspace. It finds docs, tables, files, people, and chat messages. That is the useful claim I can make about it. I do not describe it as finding every task or every possible piece of content.

Links and mentions give people a way to point to existing work. Notifications use a shared inbox and settings rather than asking someone to manage an independent notification system for each kind of content. Different events still deserve different treatment: a mention and a change to something you watch are different reasons to notify you.

A unified interface follows the same principle. A document needs an editor; a whiteboard needs a canvas. Consistency means that the surrounding workspace uses shared patterns. It does not mean forcing every activity into the same screen.

Shared sign-in solves a different problem

Separate apps can share a sign-in, exchange links, and synchronize information. Those connections can be useful. A shared sign-in gets a person through the door; synchronization moves information between places.

Neither arrangement, by itself, establishes one model for the work. If a task exists in one system and a conversation in another, the integration still has to decide what crosses between them, which version to trust, and how access applies on each side.

This is an architectural distinction, not a claim that every connected suite behaves alike. Some teams have good reasons to keep specialized tools. I would judge that choice by the work it supports, rather than the number of logos involved.

For Zanbase, I choose to put the everyday workspace on one foundation. I want the connection between a doc and a conversation to be a relationship inside the product we build, instead of a separate integration we must maintain between our own features.

The harder work belongs to us

This choice is harder and slower to start. A shared capability has to serve more than its first screen. A permission rule must make sense for a doc and for the other resources that depend on it. A change to the shared interface needs care because it reaches more than one feature.

The alternative is to let each feature solve its own problems independently. That can make the first implementation easier to isolate. I reject it as our default because every independent solution creates another concept for the team to maintain and for people to learn.

Our engineering rule is to build a shared capability once. When two features need the same behavior, it belongs in their shared foundation. That creates a demanding review question: does this feature describe something specific to its work, or does it introduce a second way to do something the workspace already does?

The cost is real design work before a feature feels complete. I accept that cost because consistency needs to survive beyond the first set of screens.

A practical standard for the product

The standard I use is a concrete sequence: open a brief, discuss a decision, follow its reference, and act on the work. At each step, ask what the person has to learn again and what information they have to copy.

You can use the same sequence when evaluating Zanbase. Start with finding your way around the workspace, then try a small piece of work that involves both a doc and a project. Check the access and the references as carefully as the editor.

I do not expect putting everything in one app to make a team organized by itself. Someone still needs to write down decisions, choose owners, and connect the relevant work. My responsibility is to build a workspace where those choices fit together, with fewer separate systems for the team to reconcile.

Products used

• Chat
• Docs
• Projects
• Tables