For most small businesses it is not merely an alternative to a native app, it is the better answer. The costs it removes are substantial: no separate build for each platform, no review process before every change, no store fees, and no user having to decide to install something before they can use it. Somebody arriving from a search result is already inside it, which is the barrier native apps never fully solve.
The limitations are real and worth knowing before deciding. Access to certain device capabilities is more restricted than a native app enjoys, and support for some features varies by platform, with notifications historically being the most inconsistent. If your product depends on deep hardware integration, background processing, or being present in a store where people search for things like yours, those are genuine reasons to build native.
That last point is worth separating out. Some businesses want an app for discovery rather than function, because their customers browse the store. That is a marketing argument rather than a technical one, and it is legitimate, but it should be stated plainly rather than dressed as a capability requirement.
The practical route is to build the website well, add the capabilities that make it installable, and see whether anybody installs it. That tells you something a survey cannot: whether your customers want an icon on their phone for what you do. If they do, you have learned it cheaply, and a native build later starts from a validated assumption rather than a hopeful one.
One practical detail affects whether people actually install it. Nothing prompts them to unless you do, since the browser mechanism is discreet by design. A short, well timed message inviting somebody to add it to their home screen, shown after they have used the site rather than on arrival, is what converts a capable web application into one that people keep. Businesses that build the capability and never prompt for it typically see almost no installations and conclude the technology does not work.