In a CRM where every association type has an inverse row (A->B and B->A) and a labeled link implies the unlabeled one, a "primary company" label is often modeled symmetrically, so the label shows on both records. Rules like "first company becomes primary", "a contact with companies must always have exactly one primary" and "replace the primary" then break: immediate checks fail mid-transaction (remove old primary before adding the new one), and bulk operations such as record merges or imports that delete and reinsert links trip the rules in the wrong order.

A custom report that joins a primary object to secondary objects through an association table (deals -> contacts -> companies) multiplies rows: a deal linked to two contacts appears twice, so SUM(amount) or AVG over the joined rows double counts inside a single group, and totals drift from what users expect from CRM-style report builders.

A web app talks to Postgres with a superuser-like role (BYPASSRLS), so row-level security policies never apply to its queries. Adding multi-user permissions (view/edit/delete scoped to own records, team records, or all, plus sharing) by sprinkling checks into each server action is fragile: one forgotten action, export, count, or search leaks or modifies data.