Rejection should be silent
If a product has to tell someone they weren't chosen, the design has already failed. Building the absence of a state turns out to be a real constraint.
One of the first hard rules I wrote for the product I’m building was that rejection is always silent. When someone asks to join something and the host closes the pool without them, nothing happens. No notification, no state change they can observe, no polite message explaining they weren’t picked.
It sounds like a small courtesy. In practice it’s one of the most far-reaching constraints in the system, because there is no rejected state to build — anywhere. Not in the data model, not in the notification system, not in the screens nobody has designed yet. Every future feature inherits it.
That’s the part worth generalising. Product principles that live in a document get quietly violated by the third engineer who wasn’t in the meeting. Principles that are expressed as a missing column, a missing enum value, a missing endpoint are much harder to violate, because reintroducing them requires someone to actively build the thing back.
The same logic applies to the follower graph the product doesn’t have, and to the trust signals that only count upward and never display a percentage. Each one was cheaper to make once, structurally, than to defend repeatedly in review.
The cost is real: you lose the ability to change your mind cheaply. A silent rejection can become a visible one later, but only by building something new. That’s the trade — and I think for consumer products dealing with social risk, it’s the right one.