Services
Every engagement has a defined scope and a written deliverable. You should know what you are getting before it starts, and be able to point at it afterwards.
Multi-tenancy isolation review
Where we are strongestFind out whether your tenant isolation actually holds — before a customer does.
We examine how tenants are resolved, how that context travels through your application, and what the database actually enforces. Most reviews find at least one path where isolation depends on someone remembering to write a predicate, and often one where it was never applied at all.
- You get
- A written report: what is exposed, why, and the order to fix it in.
- Good fit when
- Teams running multi-tenant SaaS on Postgres, especially before a security questionnaire or a first enterprise deal.
Architecture review
An outside read on a system you are about to commit to, or already regret.
A focused review of one system or one decision — data model, service boundaries, consistency, failure modes. Written for the engineers who have to live with it, not for a steering committee.
- You get
- A written report and a readout session with your team.
- Good fit when
- Before a rewrite, before a migration, or when a design keeps being argued about without resolution.
Design partnership
A senior architect in the room, without hiring one.
Ongoing involvement in your design decisions: reviewing proposals, pairing on hard problems, and writing the documents that let a team move without re-litigating the same question every sprint.
- You get
- Recurring engagement, scoped monthly.
- Good fit when
- Teams growing past the point where architecture happens by accident.
Why us for this
We build multi-tenancy infrastructure for a living, in the open. TenantLayer is an Apache-2.0 library where every isolation claim is mutation-tested — the implementation is deliberately broken to confirm the test catches it.
You can read the code, the tests and the reasoning before you hire us. That is a stronger basis for a decision than a case study you cannot verify.
It also means we know the specific ways this goes wrong: isolation that was never applied because the application connects as a superuser, context that silently stops travelling across a thread boundary, a cache that serves one tenant’s data to another because a cache hit never reaches the database.
How it starts
- 1.A conversation — Thirty minutes on what you are worried about. Free, and if it is not something we are right for, we will say so.
- 2.A written scope — What will be examined, what you will receive, what it costs, and by when.
- 3.The work — Mostly asynchronous. We will need read access to the relevant code and time with one or two of your engineers.
- 4.The deliverable — A written report, and a session to walk your team through it.