Web vs. native: when a single constraint decides the whole architecture
The choice between web and native is rarely decided by technology preference. It's almost always decided by a non-functional requirement that seems secondary until it isn't.
The "web vs. native" debate usually gets framed as a matter of preference or development speed: the web iterates faster, native gives a better experience. That framing is comfortable, but it's almost never what actually decides the project. In practice, the decision is usually determined by a single non-functional requirement that, if ignored early on, forces a costly migration later.
The case that exposes the problem
Picture a system with two types of users: an administrator managing information from an office, and a field coordinator who needs to receive a notification, reliably, for real, even with the app closed, when a critical event happens on site.
For the administrator, a web application is, without question, the right choice: no installation friction, instant updates, and no requirement that depends on running in the background. For the field coordinator, the question changes entirely, because the guarantee they need, receiving a reliable push notification, even with the browser or tab closed, isn't something the web can offer with the same certainty as a real native or cross-platform app.
Why "push notifications" isn't a checkbox that means the same thing everywhere
Web push notifications depend on the browser keeping a subscription alive and on the operating system treating that page as worth waking up, a much weaker guarantee, and much less consistent across platforms, than what a native app registered directly with the device's notification system offers. If the business depends on that notification arriving, because otherwise someone doesn't respond to an emergency in time, the difference between "it'll probably arrive" and "it's guaranteed to arrive, with retries managed by the OS itself" isn't a minor technical detail. It's the difference between a reliable system and one that fails silently at the worst possible moment.
The right architecture isn't "all native" or "all web"
The productive conclusion isn't "let's go all native to be safe," that sacrifices iteration speed where it isn't needed. The conclusion is to segment the architecture based on what guarantee each type of user actually needs, and accept that the same product can have a web frontend for whoever doesn't need that guarantee and a native or cross-platform app for whoever does.
This requires resisting a very common pressure in product teams: the preference for a single stack "for simplicity." The simplicity of maintaining one frontend is real, but it isn't free. The cost gets paid in exactly the reliability the most critical use case needs.
The question to ask before picking a stack
It isn't "what's faster to build?" or "what does the team prefer?" It's: what's the strictest guarantee some user of this system actually needs, and which technology can genuinely deliver it? Once that question is answered, the rest of the architecture gets organized around it, not the other way around.