PWA in an Online Store: What It Is and When It’s Worth It

A Progressive Web App (PWA) is marketed today as a store icon on a phone screen, but along with it, you’re buying something much bigger: a way of building a store where the front end is a separate system that communicates with the backend via an API. The same name can refer to both a plugin thrown together in a single afternoon and a project on which several people work for months - yet on a phone, they both look similar. That’s why the question “PWA or native app” leads in the wrong direction. It’s better to ask what your store needs to do under the hood. We’ll walk through both questions using the stores we’ve built and maintain as examples.

What is a PWA (Progressive Web App)?

A Progressive Web App (PWA) is an online store built as a website that behaves like an app. It opens in a browser, can be added to your phone’s home screen, and from then on, you can launch it using the icon without installing anything from the app store.

To the buyer, it looks completely normal. They visit the store from their phone, the browser suggests a shortcut, and after adding it, the page opens in full-screen mode, without an address bar or anything that resembles a website. Part of what they’ve already downloaded remains in the device’s memory, so the store doesn’t fall apart when signal strength is low. A PWA can also send notifications, though the OS vendor sets the conditions, and we’ll come back to that later. Such a store can, in fact, be distributed through Google Play: since 2019, Android has allowed websites to be packaged as app store listings, so users download it just like any other app, even though the same website runs underneath it as it does in a browser.

However, this description has a flaw. It applies equally to a plugin added to a store that’s already up and running and to a store that’s been completely rebuilt from the ground up. They look the same on a phone, but what sets them apart is what you can’t see.

Sticker or architecture: two things we call PWA

The difference begins at the foundation.

A sticker is a layer added to a store that’s already up and running: it applies app-like behavior to the existing site, and that’s where it ends. Architecture means that you build the store differently from the ground up. You have a backend with sales logic, an API layer that exposes that logic to the outside world, and a separate front end that uses it. Someone has to build each of these three components, integrate them with the other two, and maintain them for years to come. The PWA technology is exactly the same in both cases. The scale of the project, however, is not.

This is where the most common mistake in implementation stems from. The conversation veers toward whether we’re enabling a PWA, rather than how we’re designing the store. You install the plugin, and you can turn it off on Monday. You live with an architecture for a few years, so this decision is made once, with your eyes open.

When the front end is decoupled from the backend, something happens that you won’t read about in PWA sales pitches - and it can end up being the most expensive part for the store. Google must receive ready-to-use HTML. If the front end assembles the page only in the user’s browser, indexing can be delayed, cover only part of the content, or produce different results each time. In the worst-case scenario, the bot receives an empty shell and sees a store with no products. There’s only one reliable option: a server-side rendered page or one prepared in advance, so that the search engine has the full content from the very first second.

Does a PWA hurt SEO? No, if the front end is server-side rendered. That’s how we do it. The online store we’ve been running for several years provides bots with complete HTML; the bots go directly to the address they’re given, without our redirects to the correct channel or country, and the product, catalog, and blog pages have the correct language version tags. The only issue arises with PWAs that assemble the page only in the browser. The rendering method is chosen by the developer, so be sure to ask about it before signing a contract.

Mobile is a separate issue. Since July 2024, Google has indexed pages exclusively with a bot that behaves like a smartphone, so a store that doesn’t work on a mobile device won’t be indexed. This is a requirement for every online store, not an argument in favor of PWAs: a standard responsive store meets this requirement just as well, and most stores have been meeting it for years.

PWA, native app, or a standard responsive online store

In meetings, this question almost always comes up in one form or another: PWA or native app. We respond by saying that it’s the wrong question to ask, because it assumes two ready-made products sitting side by side on a shelf. In practice, there is a single axis of complexity. At one end of this axis are solutions closer to a regular website - cheaper and faster to launch - while at the other end is full control over what the phone does, with separate code for two systems and a separate release cycle. So a slider that you position somewhere along this axis is closer to the truth than a toggle with two positions.

A standard responsive online store also falls along this spectrum, but at the very bottom. For most stores, this is still the right place, and there’s nothing wrong with that.

There’s another assumption in this question - one that’s much more costly. The app and the website aren’t competing for the same space. They’re two channels in a single funnel: one attracts people who are just discovering you, while the other serves those who keep coming back. The “either-or” mindset pushes companies to rewrite a functioning website as an app, rather than adding an app where it actually adds value.

This is how it works for a client we built an app for. At Bolero, the app was built in React Native and talks only to our account and data layer, while Magento remains the single source of truth that orders are synced back to on a schedule. The store continues to operate as usual; the app exists alongside it as a separate channel and does not contain a single copied sales rule. Whether such a channel will pay off is a completely different question, and we’ve explored it in our article on mobile apps as a separate business.

An app never replaces the web. Alongside it, or not at all.

What a PWA can’t do on iOS, and whose decision that is

Eight years. That’s how long it took from the moment push notifications started working in the Android browser to the day Apple allowed them. Chrome got them in 2015. They didn’t appear on the iPhone until iOS 16.4, in March 2023. The technology itself didn’t change along the way; what changed was the OS vendor’s consent.

Notifications in PWAs on iOS have two conditions. The user must first add the store to the home screen and then request notifications by clicking a button in the store. You cannot send anything from a tab open in a browser, even if the store has been ready for a month.

There’s a certain pattern here, and it’s more important than the date itself. What a PWA can do on a specific phone is determined by the company that sells that phone. The web standard specifies what’s possible, and the operating system either allows it or delays it for a few years.

The year 2024 clearly demonstrated this. Apple, citing the EU’s DMA, announced that it would disable launching apps from the home screen in Europe, and managed to test this in beta versions of iOS 17.4. On March 1, 2024, it backed down before the system’s release, and European apps continue to function to this day. For a store owner, the implication is practical. Things may change at this level, even though you haven’t changed a single line of code, and it’s not up to you to decide. It’s worth knowing which store features stand on someone else’s ground and not to base your entire sales strategy on them.

When a PWA in an online store pays off, and when it just costs more

Is your store ready for a PWA? A headline like this almost always implies an affirmative answer, because the question is asked by someone who has something to sell. Let’s flip it around. When is a PWA in an online store an unnecessary expense? It’s worth it when the store has real underlying complexity - for example, multiple channels and markets - and needs its own design and a mobile-optimized front end. When that’s not the case, it just costs more.

A split store costs more because, instead of a single system, you maintain several interdependent components, each with its own release cycle and its own set of issues. In return, you get a store that you couldn’t have any other way: a design independent of what the platform’s template allows, and a mobile-first front end from day one.

Sometimes you pay more and get nothing in return. That’s how it ends when a front end is forced onto an old monolith, to which someone added an API solely so the project summary could say “we have a PWA.” Data still travels along the same paths as before, the platform’s limitations haven’t disappeared, and the customer doesn’t notice anything other than a new icon. You paid for a split system, and you have the same store - only with one more layer of maintenance.

There is one more factor that isn’t visible in the quote but can be decisive. After implementation, someone has to oversee the backend, the API layer, and the front end all at once, and people who can do all three simultaneously are expensive and few and far between. The question then shifts from “how much will I pay” to “do I have the right people to fill these roles,” and that’s a completely different problem.

A sensible recommendation stems from the company’s maturity, not from technology. A small store with a single offering in a single market will gain the most by tidying up and speeding up what it already has. There’s no point in copying the complexity of larger organizations: their fixed costs will come along with it, and no one will contribute additional revenue to cover them.

A store that is growing and beginning to expand across multiple channels can start from the middle. Organize the data and expose it via an API, even if the front end remains the same for now. This approach is convenient because the API layer is useful from day one - even without a PWA - and you can decide on a separate front end a year later, by which time you’ll have data to feed it.

A large organization with its own team usually doesn’t ask whether to build a separate store, but rather what to migrate first. A massive migration in a single go - across all markets and all views - ends up being the most expensive option. It’s better to choose one channel or one country, see it through to the end, and only then consider the rest.

When asked how long it will take and how much it will cost, the honest answer is: it depends, and it depends on several factors. It depends on the number of channels and markets, because each adds its own currency, language, taxes, and shipping rules. It depends on how many systems are running on the backend, because integrations with ERP or the warehouse take more time than the front end itself. It depends on whether you provide the view designs or we create them in-house, and how much needs to be migrated from the old store, since order history, accounts, and addresses sometimes take longer to transfer than it takes to build the new front end.

The largest item in this calculation isn’t listed in any table. A bigger check doesn’t fix scarcity.

How we do it

Someone opens the store from a British IP address. Before the browser has anything to render, the front end already knows it’s the UK channel: prices will be calculated in pounds, text will be displayed in English, and the shipping options shown will be those that actually work in that region. This is determined on the server side based on the country specified by the CDN layer and is stored in a cookie so that on the next visit, no one has to ask any questions. These are precisely the redirects that we disable for bots.

The store is called Cumulus and has five channels: Poland, the European Union, the United Kingdom, North America, and one collective channel for all other countries. Each channel operates in its own currency, displays prices in its own way (some show net prices, others gross), and uses its own system of measurements, because the same item listed in centimeters and inches appears as two different product pages to the buyer. Today, it runs on Magento with our tech stack and a PWA front end, following a migration from an older Magento installation. It’s only with this kind of configuration that you can see why a separate front end is necessary. Most of the work goes on behind the scenes, not in the design: five sales channels draw from a single shared inventory pool to ensure that the same item isn’t sold simultaneously on two markets, and all it took was configuring a module from our platform.

The second example is based on a different foundation. 7000obrotów sells motorcycle and auto parts, has over 800,000 products in its catalog, runs several stores on a single installation, and receives data from its ERP system and a supplier’s API. Our PIM serves as the central catalog there, because with such a large number of items, everything else depends on whether someone is maintaining a single source of truth.

A PWA storefront is our standard front end for B2C stores, and the views are either provided by the client as finished designs or created in-house. The backend behind it varies, including Magento.

Such a front end doesn’t necessarily have to support online sales, anyway. For Bioderma, we built a PWA catalog that works at points of sale: it appears on screens right next to the shelf with the brand’s products in Super-Pharm drugstores and, after a short quiz, recommends a cosmetic product to the customer.

Summary

In ecommerce, in the long run, simplicity prevails. Every layer you add must pay for itself - not because it’s modern, but because someone truly needs it. The industry likes to sell architecture as a product, even though architecture is a result: it stems from what the store is supposed to do at its core. That’s why we view it without enthusiasm and without fear. We’re betting that the browser will become the default shopping platform, while a standalone app will be a niche for those who return on their own. So the final question isn’t about choosing a technology. What in your store today is so complex that it’s starting to get in the way without a separate front end?

If you’d like to test this on your own store, schedule a free consultation. We’ll go through these decisions one by one and explain what they mean for the scope of implementation.