Monesize Desk: Engineering an Independent Product Around the Monesize Ecosystem

Monesize Desk started from a different architectural position than Monesize Core. Core was the platform from which the broader Monesize architecture evolved. Desk came later, when we wanted to build a product that could operate independently while still participating in the Monesize ecosystem.

That created a different engineering problem. The question was no longer simply how to build another module inside Core. It was: how do you build a completely independent product that has its own backend, database, tenancy model, authentication flows, business logic, and deployment, while still allowing it to participate in a shared product ecosystem? Desk became one of the first concrete implementations of that model.

Desk Is Not a Core Module

The easiest way to build Desk would have been to add customer support functionality directly into Core. That would have made some things simpler. The product could share Core's database. It could share Core's authentication. It could reuse Core's existing application infrastructure. But that would also make Desk dependent on Core in ways that would become difficult to undo later.

Instead, we designed Desk as its own product. It has its own backend, PostgreSQL database, authentication system, organizations, users, tenancy model, business domains, deployment, and configuration. Desk can therefore be developed and deployed independently. The relationship with Core exists at the ecosystem boundary rather than inside every Desk operation. That distinction became one of the most important design decisions in the project.

Why Build It Independently?

Building an independent product introduces more work. There is no reason to duplicate authentication, tenancy, and infrastructure unless independence provides a meaningful benefit. For Desk, it did.

The product needed to be able to evolve independently from Core. Its domain model is different. Its operational workflows are different. Its customers are different from Core's financial records. A ticket is not an accounting transaction. A support agent is not necessarily a Core user with access to financial operations. A customer using a support portal should not need access to Core. That meant Desk needed its own application boundary. At the same time, users should not have to exist as completely unrelated identities across the Monesize ecosystem. That was where the identity trust architecture became important.

The Identity Problem

Once products become independent, authentication becomes more complicated. If Desk has its own authentication system, how does it establish that a user authenticated by Core is legitimate?

The obvious but undesirable answer would be to share authentication secrets or allow Desk direct access to Core's database. I did not want that. The architecture instead established a trust relationship between the products. Core can issue a signed identity token. Desk does not need Core's authentication secrets to trust that token. Instead, the ecosystem provides a mechanism through which Desk can verify the identity cryptographically. This became the foundation for independent products within Monesize.

The Gateway

The Gateway sits between Core and independently deployed products. It provides the controlled boundary through which products can participate in the Monesize identity system, handling tenant public-key registration, issuer-based tenant resolution, JWT signature verification, identity exchange, tenant resolution, and failure handling.

Core uses tenant-specific RSA key pairs and RS256-signed identity tokens. The receiving product can verify the signature using the appropriate public key without having access to Core's private signing key. This creates an important separation. Desk can trust an identity without trusting Core's database. It can verify a token without sharing Core's authentication secrets. And Core does not need to become the database behind every Monesize product.

Tenant Resolution

Identity alone was not enough. A user can belong to more than one organization. Desk therefore needed to understand not only who the user is, but which organization they are acting within.

This influenced the authentication design. Desk users are tenant-scoped, so an email address is unique within an organization rather than globally across the entire Desk system. The same email can legitimately have memberships in multiple organizations. During authentication, Desk can discover the organizations associated with an identity and let the user select the organization they want to enter. Once the organization is selected, the rest of the application operates within that tenant context. This distinction matters because identity and tenancy are related, but they are not the same thing.

Tenant Isolation

Desk uses application-level tenant isolation rather than PostgreSQL Row Level Security, which means tenant boundaries are enforced by the application and data access layer. Every tenant-scoped database operation must carry a tenant identifier.

To reduce the possibility of accidental omissions, Desk uses a guarded Prisma client. If a tenant-scoped query is attempted without the required tenant scope, the client rejects it. The goal is to make tenant isolation a property of the data access architecture rather than simply a convention that every developer needs to remember. This became particularly important as Desk grew. A multi-tenant application can contain hundreds of queries, and relying entirely on individual developers to remember a tenantId condition everywhere is not a strong enough boundary. The application therefore makes tenant scope explicit.

A Narrow Cross-Tenant Exception

There is one deliberate exception. Authentication sometimes needs to resolve information across tenants. A user may have the same email associated with multiple organizations, for instance. Desk therefore has a narrow identity-resolution path specifically for authentication and organization selection, and that logic is isolated rather than allowing arbitrary cross-tenant access. Once the tenant has been selected, normal application queries return to the guarded tenant-scoped data access layer.

This distinction is important. Cross-tenant identity resolution exists because authentication requires it. It does not become a general-purpose mechanism for querying customer data across organizations.

The Desk Domain

With the product boundary established, the next problem was the actual service management platform. I designed Desk around several related domains: tickets, teams, customers, a knowledge base, attachments, notifications, analytics, and a customer portal.

Each domain has its own responsibilities. Tickets manage the support lifecycle. Teams manage agents and organizational membership. Customers represent the people or organizations receiving service. The knowledge base provides self-service information. Notifications help agents stay aware of changes. Analytics provides operational visibility. The portal gives customers a way to interact with support without becoming internal Desk agents. The product therefore extends well beyond a basic ticket queue.

Ticket Lifecycle

Tickets are at the centre of Desk, but even the ticket itself is not just a record with a status field. A support workflow can involve creation, assignment, messages, escalation, reopening, status changes, agent ownership, and customer interaction. Desk provides explicit operations around those transitions.

This matters because service management is fundamentally about workflow. The system needs to represent not only what a ticket currently looks like, but the actions that caused it to reach that state. That also creates opportunities for notifications, analytics, and escalation workflows.

Teams and Agents

Support organizations are rarely just collections of tickets. People need to work on those tickets. Desk therefore has a team and membership model that separates organizational structure from individual ticket activity. Agents can belong to teams and receive assignments, and roles determine what users are allowed to do within the platform.

This creates another layer of authorization on top of authentication. Knowing who a user is does not tell Desk what that user is allowed to do. The application therefore separates identity, tenancy, and authorization.

Customer Management

A support system also needs to understand the people it serves. Desk has a customer directory that allows customer identities to exist separately from internal agents. This matters because customers and support personnel have different relationships with the system. An agent needs access to operational support data. A customer should be able to interact with their own tickets without gaining access to internal organizational data. That distinction eventually led naturally into the customer portal.

The Customer Portal

The portal allows customers to interact with Desk without being internal Desk users. Customers can access support workflows through their own portal session. This creates another authentication boundary. The portal needs to establish who the customer is and what organization they belong to without giving them the permissions of an internal Desk agent.

The result is a system with several distinct identity contexts: internal Desk agents, organization administrators, external customers, and Monesize ecosystem identities. Keeping those contexts separate prevents the internal application model from becoming the customer-facing model.

Knowledge Base and Self-Service

Support does not always need an agent. A customer may be able to answer a question by reading an existing knowledge base article. Desk therefore includes a knowledge base as part of the service model. This changes the role of the platform slightly. It's not only a place where organizations respond to tickets. It can also become a place where organizations publish information that prevents some tickets from being created in the first place. That makes self-service part of the support workflow rather than a completely separate product.

Attachments and Object Storage

Support conversations often require files: screenshots, documents, logs, other supporting material. Desk therefore supports attachments through Amazon S3. The application does not need to proxy every file directly through the backend. Instead, the backend can generate pre-signed upload and download URLs, which provides a cleaner separation between the application API and object storage.

Attachments are also entitlement-controlled. A limited organization cannot simply access the attachment system because the endpoint exists. The server enforces the plan restriction. This matters because entitlements are not treated as frontend visibility rules. They are backend authorization rules.

Plans and Entitlements

Desk has three plan contexts: INTERNAL, CORE, and LIMITED. The distinction matters because Desk is part of the wider Monesize ecosystem. A limited organization can use the core service capabilities while certain functionality remains unavailable. Attachments, for example, are blocked server-side for LIMITED organizations, and the restriction is enforced by the backend rather than merely hiding the feature from the interface.

When an organization completes Core onboarding and moves from LIMITED to CORE, the entitlement state changes. This provides a foundation for extending product capabilities without embedding plan logic into every individual frontend component.

Real-Time Communication

Support applications benefit from real-time updates. An agent shouldn't necessarily have to refresh a page to discover that something changed. A new ticket message, assignment, notification, or other event can require immediate visibility. Desk therefore uses Socket.IO for real-time communication. The real time server is initialized alongside the HTTP application and provides a channel for delivering relevant events to connected clients.

This is another example of using a communication mechanism based on the actual problem. The normal HTTP API handles request-response operations. The real time layer handles events that need to reach connected users without waiting for another request.

Email

Email is another important part of support workflows. Desk integrates with Amazon SES for email delivery. The email service is initialized as part of the application startup process and remains available to the platform for outbound communication. This allows the product to communicate with customers and agents without coupling the ticketing domain directly to the email provider's implementation. The same principle applies here as elsewhere in the architecture: the business domain needs to express that an email should be sent, and the infrastructure layer handles how that email actually gets delivered.

Analytics

A service platform eventually needs to answer questions beyond individual tickets. How many tickets are being handled? How are agents performing? How quickly are tickets moving through the system? Where are support workloads concentrated? Desk therefore includes ticket and agent analytics, with access restricted to appropriate managerial and administrative roles. This is another example of the relationship between data and authorization. The existence of an analytics endpoint does not mean every authenticated user should be able to query it.

Why Desk Has Its Own Database

One of the most important consequences of making Desk an independent product is that it has its own database. Desk does not need Core's database to operate. This provides several benefits: the Desk data model can evolve independently, Desk deployments can be managed independently, and a Desk failure does not require the Core database to be available for every normal operation. The support platform can scale and change according to its own requirements.

Most importantly, it preserves the architectural boundary between the products. Core provides ecosystem-level trust. Desk owns Desk's operational data. That separation is intentional.

The Developer API

Desk originally provided its own customer portal for organizations that wanted a ready-made support experience. But there was another obvious use case: organizations that already have their own product and want support to feel native to it.

Instead of forcing those organizations to send customers to a separate Desk portal, Desk now exposes its support infrastructure through a public API.

The API allows an organization to build its own customer-facing support experience while Desk remains the underlying system for tickets, customers, conversations, attachments, teams, assignments, escalations, and knowledge.

The separation is deliberate. The organization's product owns the customer experience. Desk owns the support operation behind it. Support agents can continue working from the normal Desk workspace without needing to know how the customer-facing experience was implemented.

Test and Production Environments

The API provides separate test and production environments for each organization. Test credentials operate against an isolated test tenant, allowing developers to build and experiment without creating data in the organization's real support workspace.

Production credentials operate against the organization's real Desk tenant and allow live customer interactions to appear in the agent workspace.

API credentials are organization-scoped and can only be created or managed by organization administrators. The developer documentation itself remains publicly accessible so developers can understand and evaluate the API before having to authenticate.

Desk as Infrastructure

This changed the role of Desk slightly.

Desk is no longer only an application that organizations log into. It can also sit underneath another application as its support infrastructure.

A company can build its own "Help & Support", ticket history, customer conversations, or support portal directly into its product while Desk handles the underlying support data and workflows.

That creates two ways to use the same system: organizations can use the Desk portal directly, or they can build their own experience on top of the Desk API.

The API is intentionally provided as part of Desk rather than as a separate infrastructure product. The goal is simple: organizations should not have to build an entire support backend just because they want support to feel native inside their own software.

The Core Bridge

Desk still needs to participate in the Monesize ecosystem. That's where the Core bridge comes in. Desk exposes protected gateway endpoints for identity exchange and tenant resolution, and the gateway is protected using a dedicated API key. Identity tokens are verified through the broader gateway trust mechanism rather than by giving Desk direct access to Core's internal authentication system.

This creates a useful pattern: Core owns the ecosystem identity, Desk owns the Desk product, and the Gateway establishes the trust between them. That is the architecture I wanted to prove with Desk.

What Desk Proved

Building Desk provided a practical test of an architectural idea that had previously existed mostly at the platform level. Could an independent Monesize product actually work this way, with its own database, its own users, its own tenant isolation, its own authentication, its own business logic, and its own deployment, while still participating in the identity ecosystem?

The answer is yes. Desk became a concrete implementation of the architecture that had evolved around Core. That's what makes Desk particularly important in the Monesize engineering story. It isn't simply another application. It demonstrates that the platform boundary actually works.

What I Learned Building Desk

Desk reinforced several lessons from Core while introducing new ones.

The first was that independence requires deliberate boundaries. It's easy to make two applications communicate when they share everything. It's harder when they have to trust each other without sharing their internal state. The second was that identity and data ownership should not be confused. Core can establish who a user is without owning Desk's operational data. The third was that tenant isolation needs to be enforced structurally, since a growing application cannot rely solely on developers remembering every security convention. The fourth was that product entitlements belong on the server. If a feature is unavailable to a plan, the backend needs to enforce that restriction. And the fifth was that an ecosystem should not require every product to become another module inside one giant application.

From Platform to Ecosystem

The most important thing Desk represents is a change in what Monesize itself can be. Core started as the primary platform. As the architecture evolved, it became possible for other products to exist around it.

The shape of that architecture now runs from Monesize Core, through its identity and trust layer, into the Gateway, which sits as the shared boundary that any number of independent products can connect to. Monesize Desk is one of those products, sitting on the other side of that boundary with its own database, its own backend, its own tenancy, and its own workflows, and other products can eventually sit alongside it the same way.

The products do not need to become one application. They only need a reliable way to establish trust and exchange the information necessary to participate in the ecosystem. That is the architectural direction Desk helped validate.

Conclusion

Monesize Desk began as a product that could have been implemented as another module inside Core. Instead, it became an opportunity to test a more ambitious architectural model. The product has its own backend, database, tenancy model, authentication, business domains, and deployment. It manages tickets, teams, customers, knowledge, notifications, analytics, attachments, and customer self-service. It uses real time communication where it's useful, object storage for attachments, email infrastructure for outbound communication, and server-side entitlements to control product capabilities.

But the most important part of Desk is not any individual feature. It's the boundary between Desk and Core. Core does not need to become Desk. Desk does not need access to Core's database. Desk does not need Core's authentication secrets. Instead, the two products establish trust through an identity and gateway architecture that allows them to remain independently deployed.

That was the real engineering experiment. Could an independent product belong to the Monesize ecosystem without becoming dependent on the internals of Monesize Core? Desk is the answer.

Desk also demonstrated that the product could extend beyond its own interface. With the exposure of its support infrastructure through a public API, Desk can serve both as a complete support workspace and as a backend layer for products that want to build their own customer-facing support experience.