David Oduse

Monesize Desk was originally built to be a product people use directly. Then we started thinking about what would happen if we stopped treating the Desk interface as the product. Monesize Desk has always been a single-tenant-isolated support platform. Every row in the database is scoped to an organization, and every agent-facing endpoint authenticates through a session cookie. That model is great for a hosted workspace, but it does not help an organization that wants to embed support inside its own product. The public API extension changes that. It exposes the same support infrastructure Desk already provides, through a machine-to-machine interface that products can call directly. This post walks through the design: the key model, environment isolation, authentication middleware, the request surface, and the failure modes. It's a deep look at how the extension is built on top of the existing Desk core. The Core Idea Desk now supports two consumption models. The Desk porta...

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 Co...

When I started building this, Monesize was in the middle of a quiet transformation. It was no longer one product. It was becoming a product ecosystem: Core, the operational financial backend; the Gateway, a centralized trust and compliance layer; and Desk, a customer support product that would sit alongside them. Each one was an independent deployment. Each one had its own databases, its own sessions, its own authorization models, its own frontend, its own lifecycles. Almost immediately I ran into the question that would shape everything after it. A user of Core is not automatically a user of Desk. The same person exists inside multiple products. So how does Desk know that a request claiming to be David is actually David? How does Desk trust the identity that Core has already established? And more specifically, how do I make that work when no two products share a database, and when the products are owned and deployed by different tenants? The interesting engineering question become...

I recently wanted to download an audio track from a platform that required a subscription before it would allow downloads. I did not subscribe. Instead, while the track was playing, I opened DevTools and looked at what the browser was actually doing. The player was not downloading the entire MP3 in one request. It was making HTTP range requests and receiving 206 Partial Content responses from a CloudFront-hosted media resource. After following the requests, I found that the underlying audio resource was directly accessible. That was the interesting part for me, not because I had found a way to download an audio file, but because it exposed a design question I would rather answer as an engineer: how should I actually build a subscription-gated audio streaming system? The answer is not to hide the download button. It starts much deeper in the architecture. The Actual Problem Suppose I am building an audio platform where users can listen to music, podcasts, courses, or any other audio con...