David Oduse

I use AI a lot. As a software engineer, I have experienced first-hand what it can do to productivity. The first version of Monesize took us about eight months to build with a team. I built Monesize Core largely by myself in about two months, with AI being a significant part of the development workflow. So this is not an article about how AI is useless, as it clearly is not. What bothers me is something else. There is an enormous amount of noise around AI, and much of the conversation seems to move from a small number of things we can actually observe to a very large number of conclusions that we have not established. AI can make a skilled person dramatically more productive. That is real. AI can also allow someone with little or no professional competence in a field to produce something that looks surprisingly competent. That is also real. Beyond those two things, however, I think we have accumulated an extraordinary number of assumptions. And I keep coming back to a question...

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