Notes from recent engagements

Teams often treat tenancy as an implementation detail to “add later.” In practice it is one of the earliest architectural commitments you make — even if you pretend you have not made it yet. Shared tables with a tenant_id column, schema-per-tenant, and fully isolated stacks all work. They fail for different reasons, at different scales, with different operational costs.

When we enter an engagement, we ask a short set of questions before recommending a model. How strict are isolation requirements from customers or regulators? How uneven is load across tenants? How often will you need to restore a single customer’s data? How many environments must mirror production? The answers matter more than fashion.

What tends to work early

For most B2B SaaS products in the first years, a well-designed shared database with rigorous tenant scoping, automated tests against cross-tenant access, and clear service middleware is enough. It is faster to build, easier to observe as one system, and cheaper to operate. The failure mode is not the model itself — it is inconsistent enforcement. One raw query that forgets a tenant filter can undo months of trust.

When to revisit

Signals that you have outgrown a simple shared model include a handful of tenants dominating resource usage, contractual requirements for physical isolation, or restore/backup needs that cannot be met without affecting everyone. At that point a hybrid approach — shared for most, isolated for a few — is often more honest than a full rewrite.

Whatever you choose, document the decision, the threats you accept, and the migration path you are consciously deferring. Future you will thank present you.

Agency handoffs have a bad reputation because they are often treated as a final dump of files. We plan the opposite: handoff begins on week one. Every engagement has exit criteria written early — who will own what, which rituals transfer, and which knowledge must exist outside anyone’s head.

Practically, that means a living architecture note, ADRs for consequential choices, a staging environment that behaves like production, and pairing sessions where your engineers make the changes — not just watch us make them. Runbooks are written when incidents are still fresh, not months later from memory.

Rituals that stick

Weekly demos stay in place through the overlap period. So does the same backlog tool. We avoid inventing a parallel process that evaporates when we leave. The goal is continuity of decision-making, not a binder nobody opens.

When the overlap ends, success looks boring: your team ships the next feature without us on the critical path, and the on-call rotation does not depend on a contractor’s phone.

“Move fast” and “build it right” are often framed as opposites. In our experience the useful distinction is different: which cuts are reversible, and which quietly mortgage the next two years?

UI polish can be iterative. A wrong domain model, missing auth boundaries, or a deployment story that cannot support a second environment are expensive to unwind. We help teams cut scope aggressively on features while protecting a short list of foundations — identity, tenancy strategy, observability basics, and a path to migrate data without heroics.

A practical cut list

Cut custom admin if a constrained internal tool will do. Cut exotic state management if the product surface is still shifting. Keep auditability if you are near money, health, or compliance. Keep automated deploys even when the team is tiny — recovery speed matters more when you are small.

An MVP that learns from users is valuable. An MVP that cannot absorb what it learns becomes a museum of early guesses. The craft is knowing which is which before the calendar forces the choice.