Every consumer app has a moment where someone in a meeting says "we should send a push notification when X happens." Almost every time, the right answer is: probably not. We learned this building Zetpin. Hyperlocal apps live and die on engagement, and the temptation is to lean on push to drive it. The temptation is wrong, in a specific way: the more reasons you give the OS to ping the user, the less the user trusts your icon, and the faster they slide your app into the silent tray — or uninstall it. So the rule we follow: a push notification is a contract. We're spending a unit of the user's attention and trust. If the notification doesn't pay that back, we shouldn't send it. In practice, that turns into a few constraints we apply every time we add a notification. It has to be about a person, a place, or a thing — and ideally one the user has acted on. "Someone you follow posted near you" is a notification. "Three new posts in your radius today" is not. The first is a relationship. The second is a digest, and digests belong in the app, not on the lock screen. It has to be timely or it shouldn't exist. If the notification arrives more than an hour after the event that triggered it, it's no longer a notification — it's a marketing message wearing a disguise. We set hard expiry windows on every push category. If the queue is backed up and the window passes, the message gets dropped, not delivered late. It has to be silenceable per category. Not per app. The user should be able to keep "someone replied to me" on, and turn "weekly highlights" off, without having to disable everything. Our settings screen has the same six categories as our backend's notification dispatcher. They are the same source of truth. It has to test against a real benchmark. The benchmark isn't "did the user open the notification." That's a vanity metric. The benchmark we use is: of the users who got this notification, did their seven-day return rate go up or down compared to a holdout group that didn't get it? If it didn't go up, we kill the notification, no matter how good the open rate looked. Some of this is engineering, not design. We dedupe at the backend, not the client. If a user has three pieces of activity in a window, they get one notification, not three. Bundling logic lives next to the dispatcher, and it has tests. We do not trust the client to batch. We also rate-limit per user. No user gets more than four pushes in a calendar day, ever, regardless of how interesting the events are. The limit is configurable, but no individual feature can override it. This is the most boring code in the whole pipeline and it is the one we are most strict about not removing. There's a quieter benefit to all this. When we do send a notification, the user reads it. The open rate on Zetpin's pushes is higher than the published industry averages, not because we're better at writing copy, but because we've sent fewer of them. Restraint compounds. The thing we still struggle with is the meeting where someone says "we should send a push when X." The right answer, almost always, is to ask one question first: "If we got this exactly right, how many would we send to one user in a typical week?" If the honest answer is more than one, the feature isn't a notification — it's an in-app surface in disguise. Build that instead.