01 SAAS
Other tenants
For multi-tenant SaaS, the adversary includes other tenants — not just external attackers. At scale, one will try to read another's data.
Row-level isolation Scoped authorization Tenant-scoped logs
Security starts with a question almost no one asks first. The answer shapes every architectural decision downstream — the schema, the API boundary, the audit trail, the deployment topology.
For multi-tenant SaaS, the adversary includes other tenants — not just external attackers. At scale, one will try to read another's data.
Phones get lost, cloned, rooted. The app holds enough to work for the shift — no long-lived secrets, no cached customer data that survives the parking lot.
For public web products, the adversary is bots probing for known vulnerabilities. We harden against the bottom 99% by being thorough, not clever.
Every security boundary fails eventually. The discipline is to assume that and design the next layer accordingly. The diagram below is how a request actually traverses one of our production systems — each layer independently capable of refusing the request.
An inbound request crosses five trust boundaries before it touches business logic. Each gate validates independently. Failure at any layer is contained.
Controls at each tier are the defaults — present in every project we ship. Per-engagement additions (multi-factor authentication, field-level column encryption, third-party penetration testing) are scoped to the threat model.
A checklist passed before launch is not security. Security is the set of architectural decisions that make the wrong outcome impossible — not unlikely, impossible. The work is structural, not procedural.
If we cannot answer who did what, when, with what authority, six months after the fact — the system is incomplete. The audit log is built first, not last. Every mutation traces back through it.
No service runs as root. No database user has more permission than its role requires. No endpoint trusts the caller's intent. Defaults restrict; exceptions are documented; access is reviewed.
We use standard, audited primitives. We do not invent our own. We rotate keys on a schedule, not when it becomes inconvenient. Where end-to-end encryption is warranted, the server holds nothing it does not need to.
The question is not whether a system will be compromised, but whether we can detect, contain, and recover. Backups tested by being restored. Incidents practiced before they happen. The runbook exists before it's needed.
Some projects place security in the foreground from day one. Regulated industries. Multi-tenant SaaS. Systems handling identity, payments, or sensitive operational data. These engagements follow a different rhythm.
Before architecture begins, we map the system's adversaries, assets, and trust boundaries. The document lives with the codebase and is revisited at every significant change. Without it, security decisions are made by accident.
For existing systems, a structural review of the schema, API surface, deployment topology, and audit trail. We do not run automated scanners and call it a security audit. We read code and ask the questions that scanners cannot.
Targeted remediation of identified weaknesses — auth boundaries, secrets management, audit coverage, dependency hygiene. Scoped, time-boxed, with deliverables that survive the engagement.
For systems already in production, a review of operational posture — log coverage, incident response, backup verification, access control drift, dependency currency. The work that quietly compounds value over time.
Security retrofitted is security compromised. The right time to think about it is at the schema. Reach out before the first commit, and we will help you build a system that does not need to be rescued later.