Multi-Tenancy by Design: How We Approach Tenant Isolation at RemarQable

When building SaaS software, we want to make it easy to add features and support more customers without making the application harder to maintain or less secure. One area where I think this matters a lot is multi-tenancy.

Multi-tenancy allows multiple customers to use the same application and infrastructure while keeping their data separate. It is a practical way to build and scale SaaS products, but it introduces a responsibility that can't be treated as an afterthought: making sure each customer can only access their own data.

The difficult part is that tenant isolation issues aren't always obvious. A feature can work perfectly during development and still expose another customer's records if a query or permission check is missing a restriction. The feature itself might be correct, but the way it accesses data creates a security problem.

I don't think protecting customer data should depend on every developer remembering every security rule every time they write code. I'd rather design the application so the correct behavior is the default.

Why Architecture Matters

One approach to tenant isolation is to have developers manually add the appropriate tenant restriction whenever they query customer-owned data. That can work, but it creates a problem as the application grows.

Every new feature introduces more code, and every developer working on that code needs to understand and apply the same rules consistently. Even experienced developers make mistakes, especially when working in unfamiliar parts of a codebase or making changes under time pressure.

This is why I prefer addressing the problem through architecture wherever possible. Our Python engineering blueprint's tenancy guidelines describe patterns for resolving the current tenant and automatically scoping access to tenant-owned records.

In practice, this starts with establishing which tenant a request belongs to. From there, access to tenant-owned data should be scoped to that tenant, ideally through shared data-access patterns rather than requiring every developer to remember to add the same restriction to every query.

For example, if a user requests a list of recipes, the application shouldn't simply retrieve recipes and rely on each feature to figure out which ones belong to that user's tenant. The tenant boundary should be part of how the application retrieves that data in the first place. The same principle applies when records are created, updated, or deleted: we need to ensure those operations stay within the correct tenant's boundaries.

The goal is to reduce the number of places where developers must manually enforce isolation. When the application handles these boundaries by default, there are fewer opportunities for an overlooked restriction to expose data.

That doesn't mean every operation is automatically safe. Authentication, permissions, background jobs, and other paths that access data still need to be designed correctly. But establishing consistent patterns gives us a stronger foundation than relying on individual developers to remember every requirement.

Good Standards Need Verification

Architecture helps reduce the chance of mistakes, but it doesn't eliminate them. We also need to check whether the code we write actually follows the standards we've established.

At RemarQable, our blueprint is part of that process. We use a verification agent to review changes against our documented engineering patterns and report violations that need attention. When a check fails, the expectation is to address the findings and run verification again before pushing the changes forward.

The verification process is an additional safeguard, not a hard technical block on pushing code. It also can't guarantee that every vulnerability will be found. That's why I see it as one layer of a broader approach that includes sound architecture, testing, and engineering judgment.

Testing is especially important for tenant isolation. We need to check not only that a user can access their own data, but also that they cannot access another tenant's data through unexpected requests or operations. Those negative cases matter because a feature appearing to work correctly doesn't necessarily mean the boundaries are being enforced correctly.

This is similar to how I think about AI-assisted development in How I Use AI to Develop Software Without Giving Up Engineering Judgment. Producing code and checking that code are different responsibilities. We shouldn't assume that because something was implemented successfully, it was implemented correctly.

Building for the Long Term

For me, this comes down to making software easier to maintain without compromising the boundaries that protect customer data. As applications grow, we need patterns that developers can follow consistently and processes that help identify when those patterns aren't being followed.

That also connects to what I look for when evaluating SaaS software, as I discussed in Technical Due Diligence in SaaS Acquisitions. The way an application is designed affects how confidently we can change it, maintain it, and build on it over time.

Our tenancy blueprint documents the standard we want our applications to follow. Individual applications may implement these patterns differently, but the underlying principle remains the same: prevent mistakes through design wherever possible, verify our work, and take responsibility for fixing problems when they're found.

We can't guarantee that mistakes will never happen. We can, however, make our software less dependent on perfect human memory and give ourselves better ways to catch problems before they become bigger ones.