The Enterprise Question

September 2024. A client at TVBS, the Taiwanese broadcaster, asked a question we weren’t ready for: “Can my whole team use this?”

We said yes, because that’s what you say. Then we looked at our database schema and realized “team” wasn’t a concept that existed anywhere in our system. We had users. We had subscriptions. We had billing accounts. We didn’t have organizations, teams, roles, or any of the plumbing that the word “team” implies in an enterprise context.

This is the story of how a single client question turned into fourteen months of infrastructure work.

The gap between multi-user and enterprise-ready

Our platform had supported multiple users from the beginning – each user had their own account, their own conversations, their own knowledge bases. But “multi-user” and “multi-tenant” are separated by a canyon of engineering work that’s invisible until you try to cross it.

Multi-user means: many people use the same software independently. Multi-tenant means: groups of people use the same software together, with shared resources, shared billing, and controlled access to each other’s work.

The gap includes:

• Organizations. A container for teams, with its own billing, its own settings, its own resource pools.
• Teams. Subgroups within an organization, each with different access to different resources.
• Roles. Who can create, read, update, and delete which entities. An admin vs. a member vs. a viewer.
• Resource sharing. Knowledge bases, chatbots, assistants, and templates that belong to the organization, not to any individual user.
• Transfer. Moving entities between a personal account and an organization account.
• Billing. One invoice for the whole organization, not individual subscriptions per user.

We had none of this in July 2023 when we first deployed to production. By November 2023, we’d added basic organization and team management to Dashboard v1. But “basic” is doing a lot of heavy lifting in that sentence. It meant you could create an organization and invite members. It didn’t mean you could control what those members could access.

RBAC: the feature that touches everything

Role-based access control sounds like one feature. It’s actually a cross-cutting concern that touches every other feature in the system.

Adding RBAC to our platform meant that every API endpoint needed to check: which user is making this request? Which organization do they belong to? What role do they have? Does that role grant access to this specific resource?

Each entity type required its own permission matrix. And the permissions had to compose correctly – a user who’s an admin in Organization A and a viewer in Organization B should see different things depending on which context they’re operating in.

We implemented RBAC as middleware in our API layer. Every request passes through a permission check that resolves the user’s role in the current organizational context and validates it against the requested operation. The middleware is generic – it doesn’t know about knowledge bases or chatbots. It knows about roles, resources, and operations.

Getting the middleware right took three iterations. The first version checked permissions at the route level (too coarse). The second checked at the controller level (duplicated logic). The third centralized everything in a permission service that every controller calls with a resource type, a resource ID, and an operation type.

Corporate subscriptions and domain-based enrollment

October 2024. TVBS asked the next question: “Can every employee with a @tvbs.com.tw email automatically get access?”

This is what corporate subscriptions look like in practice. An organization admin registers their email domain. Any new user who signs up with that domain is automatically added to the organization with a default role. No invitation flow. No admin approval bottleneck. Sign up with your work email, get access to your company’s AI tools.

The implementation required touching the signup flow, the organization membership system, and the billing system simultaneously. When a new user signs up:

1. Check if their email domain matches any registered corporate subscription
2. If yes, create the user account and add them to the organization
3. Assign the default role specified by the organization admin
4. Bill the usage to the organization’s account, not the individual

The edge cases were more complex than the happy path. Personal-to-org migration, multi-org membership, domain conflicts between two organizations claiming the same email domain. We handled each case – transfer system, context switcher, DNS verification. Each was a week of work that users never notice because the system just works.

The RabbitMQ backbone

Enterprise features don’t just add complexity to the application layer. They add complexity to the messaging layer.

We’d been using RabbitMQ for inter-service communication since June 2023. The original use case was simple: publish events when things happen, subscribe to events you care about. User created. Subscription changed. Workflow completed.

Organizations added a new dimension. When a user joins an organization, every service needs to know – billing, knowledge bases, chat, notifications. We ended up with five RabbitMQ handler types: wizard, approval, users, organizations, and management. Each has its own exchange and routing keys, so services subscribe only to the events they care about.

The alternative would have been direct service-to-service API calls, creating a web of dependencies. With RabbitMQ, services are decoupled. The organization service publishes an event, and whoever cares, consumes it.

The data isolation problem

Here’s the part that keeps you up at night: multi-tenant data isolation.

When Organization A and Organization B share a MongoDB cluster, every query must be scoped to the correct tenant. A search query that accidentally returns Organization B’s data to an Organization A user isn’t a bug. It’s a security incident. Depending on the industry, it might be a compliance violation with real legal consequences.

We solved this at two levels. At the query level, every database operation includes a tenant context – an organization ID that’s injected automatically by middleware. You can’t accidentally query without a tenant scope because the query builder requires it.

At the testing level, we built automated cross-tenant isolation tests. These tests create two organizations, populate both with data, then verify that queries run as one organization never return data belonging to the other. The tests run on every deployment. If they fail, the deployment stops.

This testing infrastructure was not exciting to build. But it’s the kind of work that makes the difference between a product enterprises will trust and one they won’t.

What “enterprise” actually means

After fourteen months of building enterprise features, here’s what we’ve learned about what the word means in practice.

Enterprise means audit trails. Who did what, when, and why. Every significant action in our system is logged with the user, the timestamp, the organization context, and the resource affected. Not because we wanted to build audit logging. Because compliance teams asked for it before they’d sign off on a contract.

Enterprise means no surprises in billing. Corporate subscriptions need predictable costs. The move to credit-based pricing helped here – organizations buy credits in bulk and allocate them to teams. Usage is trackable and predictable. No surprise invoices at the end of the month because one team member ran an expensive model they didn’t realize cost 10x more than the default.

Enterprise means patience. The sales cycle for an enterprise deal is measured in months. TVBS and VIA Group didn’t sign contracts after a demo. They signed after security reviews, compliance checks, technical evaluations, and procurement processes that involved people who would never use the product.

The question we keep asking ourselves

The enterprise question isn’t a technical question. It’s a strategic one.

When do you stop being a tool for individuals and start being a platform for teams? Every hour spent on RBAC is an hour not spent on new AI capabilities. Every week spent on domain-based enrollment is a week not spent on agent improvements.

We don’t have a clean answer. What we have is the observation that individual users churn. Teams stick. An individual user who finds a better tool switches in a day. An organization with custom chatbots, shared knowledge bases, team roles, and corporate billing integrated into their procurement system doesn’t switch at all.

The enterprise features aren’t the product. They’re the moat. The AI capabilities get people in the door. The organizational infrastructure makes them stay.

By May 2025, we’d added unlimited generations for organization users. Not because unlimited was the right pricing model, but because enterprise clients didn’t want to think about per-generation costs. They wanted a number on a contract, a budget they could forecast, and a guarantee that their team wouldn’t hit a wall mid-project.

The enterprise question doesn’t have a finish line. There’s always another integration request, another compliance requirement, another feature that seems small until you realize it touches every service in your architecture. But every feature we ship makes the platform stickier for the organizations that depend on it. That’s the trade-off, and fourteen months in, we’d make it again.