The user_id Column Is the Tenancy Wall: Single-Tenant by Design

No teams table, and that's not an oversight

Every monitor belongs to exactly one user_id. There's no organization model, no team, no invite flow, no concept of a monitor two people both have access to. For a product built around alerting one person or one small business about their own sites, that's a design decision, not a gap waiting to be filled.

What single-tenant buys

The account is the tenant. There's no separate concept of "who's on this team" to keep in sync with "who owns this monitor" — permission checks collapse to a single, simple question: does this user_id match the monitor's user_id. No role model, no invite state machine, no edge case where someone's access needs revoking after they leave a team that doesn't exist.

What it costs

A monitor genuinely can't be shared between two people today. If a small business wants two people to see the same alerts, right now that means two accounts watching the same sites separately, not one shared view. That's a real limitation for a growing team, and an honest one to name rather than gloss over.

Why it's the right trade for now

Most of the accounts this product serves are one person or one small business watching their own sites — not an engineering org with an on-call rotation to manage. Building a full team/permissions model before that need is common would mean carrying its complexity — and its bugs — for a feature most accounts would never touch. Simpler now, extended later if and when it's actually needed, beats speculative complexity carried from day one.