Can customers install my website instead of downloading an app?
A progressive web app can provide an installable web experience on supported browsers and devices. It may suit repeat browsing, requests or account tasks when web capabilities meet the need. Installation and device features vary, and offline behaviour must be deliberately designed. Test the actual phones your customers use before choosing it over a store app.
The key idea
Give a PWA a useful repeat task and describe its capabilities honestly; installation alone is not a business outcome.
Find a reason people would reopen it
Start with a recurring action: reviewing an order, requesting a collection or looking up a frequently used catalogue. A PWA may make that web journey easier to revisit while keeping a link available for first-time visitors. If the site mostly introduces the company, a well-made mobile website may be sufficient.
Worked example: a trade supplier has returning customers who check product specifications before asking for a quote. A focused, phone-friendly catalogue and a saved route back to it may be useful. The first release could stay simpler than a full mobile app, provided the required capabilities have been tested and the enquiry reaches staff reliably.
Make installation an option, not a barrier
web.dev explains that installation differs across browsers and operating systems. Ask the supplier to demonstrate the route on your chosen Android and iPhone combinations, including how a person removes or reopens the experience. Do not assume every user sees the same install button.
Let visitors complete the basic task in their browser first. A repeated installation prompt can interrupt someone who simply wants a phone number or appointment. Explain the benefit when relevant and keep the dismissal understandable. Your support team should know the actual steps for supported devices, rather than following instructions written for another platform.
In practice · illustrative example
Distinguish an offline reference from a live promise
Imagine a returning buyer who opens a saved product catalogue with a weak connection. Showing previously loaded descriptions may be useful. Showing an old price or stock count as if it were current can create a different expectation. Mark the boundary between information available on the device and information that needs a fresh confirmation.
Rehearse the disconnected journey before describing the product as offline-capable. What can the visitor read? What can they prepare but not submit? What happens when the connection returns? Give these states understandable wording. Installation is only one part of the experience; trust depends on whether the business action means what the screen says.
Separate cached information from confirmed action
-
Read saved content
Previously available reference information can remain useful when clearly identified.
-
Prepare work
A draft is visibly different from a submitted request.
-
Reconnect
The agreed process checks the information that must be current.
-
Confirm outcome
The visitor can tell whether the business accepted the action.
Choose what can safely work without a connection
Offline behaviour is designed; it does not appear just because a website is called a PWA. web.dev describes storage and synchronisation decisions for offline data. Decide which content can be saved, whether it may become stale and what the interface says when it cannot contact the server.
A saved catalogue might remain readable, but a current stock figure, booking slot or payment result needs different handling. If a customer composes a request offline, distinguish a saved draft from a submitted request. Only show confirmation after the agreed system has received it. On shared devices, consider what saved information remains visible to the next person.
Prove the capabilities your process depends on
List the requirements you would otherwise ask of a mobile app: camera input, location, notifications, background work or a hardware connection. Check each on the target device and browser, including denied permissions. Avoid a general promise that a PWA can do everything a native app can do.
Ask what happens when a capability is unavailable. Can staff receive a form instead of a device scan? Can a customer enter an address when location is refused? The fallback should complete the business task where possible. If the crucial feature cannot be supported dependably, compare a store app or a different workflow before committing.
Keep the public pages and the operational work clear
A PWA is a web delivery approach. Public informational content can still live in static files, while orders, accounts and bookings require their own operational services. Do not confuse an installable front end with a complete business system. Define where records go and who handles them.
At handover, request support instructions, tested device combinations, cache-update behaviour and a way to investigate failures. Check that a customer receives updated content after a change, rather than remaining on an old saved screen indefinitely. Compare the total responsibilities with a mobile website and a store app, then choose the smallest approach that reliably serves the repeat task.
A worksheet for your team
An offline behaviour checklist
Choose one returning-customer task and write what each state means before building it.
| Decision | Evidence to request | What to do next |
|---|---|---|
| Saved information | A list of content allowed to appear without a fresh connection. | Identify content that could become misleading when stale. |
| Unsent work | A test showing a draft before and after reopening. | Keep the wording separate from accepted or paid. |
| Recovery | A reconnect test with changed server information. | Explain the correction or confirmation needed. |
A deliberately limited offline experience can be useful. Define its promise precisely and test that promise instead of attaching a broad label to the product.
A practical PWA decision checklist
- One recurring task and the benefit of returning through an installed experience.
- Installation demonstrated on target browsers and phones.
- Defined offline content, draft states and confirmation rules.
- Device capabilities tested with meaningful fallbacks.
- Ownership of services, updates, support and saved data.
Frequently asked questions
Will every visitor be able to install the PWA?
Installation support and steps vary. Test the supported browser and device combinations, and keep the browser experience usable for visitors who do not install it.
Does a PWA work completely offline?
Only the deliberately implemented offline features do. Current availability, payments and submissions need explicit connectivity and synchronisation handling.
Can I replace an existing store app with a PWA?
Compare the tasks, device requirements and customers’ habits first. A PWA may suit some products, but it is not an automatic replacement for every app feature.
Sources and further reading
These primary sources support the specific company or platform information in this guide. Provider descriptions do not imply an endorsement by the source.
Sources checked:
Test your repeat task before choosing a channel
GateGold can discuss a PWA alongside a mobile website or app. Bring the task and target devices so the decision rests on a demonstrated experience.
