A developer advocates treating the User model as a stable, public API in startup backends. It’s referenced by auth, permissions, and analytics, making changes risky once real users exist. The common mistake is attaching fast-changing business logic directly to it.

Quota limits are a prime example. What starts as simple per-user counters often evolves into plan-based limits, monthly resets, and exceptions. This volatile logic on the core User table forces risky migrations, locking rows during frequent updates, and complicating deploys for unrelated queries.

The solution is a separate table for quotas, like `user_survey_quotas`, with a strict one-to-one relationship. This isolates change rates: quota models can evolve multiple times yearly without touching the stable User model. It also simplifies optional complexity, concurrency, and future rewrites.