The question usually arrives as a technical one: can a progressive web app do what we need? It is almost always the wrong question first, because both options can do most of what a product needs, and the difference that matters is how people will get hold of it.
Start with distribution. Where does the user come from, what will they already have installed, and what stands between them and using the thing for the first time?
Distribution decides more than capability
If a product is reached from a link—a message, an email, a QR code on a wall, a search result—then an app store sits directly across the path. Every additional step between intent and use costs a proportion of the people who had the intent.
If instead the product is something people return to daily, and its value depends on being on a home screen and sending notifications people act on, the store is not an obstacle. It is the distribution channel, and the install is a commitment worth asking for.
Where the web genuinely stops
The honest limits are narrower than they were, and they are still real: deep hardware access, background execution, some categories of notification behaviour, and anything that must integrate with the operating system rather than sit beside it.
The practical test is not whether an API exists but whether it is dependable across the devices your users actually hold. A capability that works on one platform and degrades on another is a support problem, not a feature.
The cost nobody prices in
A native app is not only built; it is released. There is a review process, a version people are running that is not the current one, and a long tail of old versions that still have to be supported against a moving back end.
A progressive web app moves that cost to the other side: no review, no version fragmentation, but every capability question becomes a compatibility question. Neither is cheaper in general. They are cheaper in different situations, and the situation is knowable in advance.
Deciding without regretting it
Write down how the first hundred people will arrive, which two or three capabilities are genuinely non-negotiable, and who will be responsible for releases in a year’s time. The answer usually becomes obvious once those three are on the same page.
It is also reasonable to do both, in order: a progressive web app to reach people and learn what they use, and a native application later for the parts that earn it. What is expensive is building both at once, before either has told you anything.