Chat on WhatsApp
Glossary · Magento headless framework

What is Adobe PWA Studio?

Adobe PWA Studio is Adobe’s open-source React framework for building a headless Magento 2 storefront. The React app (the Venia storefront is the reference build) runs on its own and talks to Magento only through the GraphQL endpoint at /graphql. Magento keeps the admin, catalog, cart and checkout logic; it just stops rendering the pages. It is the official headless answer for Magento, but on most stores I work on, Hyvä gets the speed and UX they want with far less code to own.

Adobe-Certified Magento + Hyvä developer 200+ Magento builds shipped: Hyvä, PWA Studio, headless
How it works

How Adobe PWA Studio actually fits together

I think of a PWA Studio build as four layers: the React frontend, the Apollo state layer, the unchanged Magento backend, and your extensions. Plan all four before the first sprint, because the last one is where projects usually stall.

  1. 01

    Frontend = React 17+ SPA hosted separately

    The storefront is a React single page application that you build and deploy on its own, separate from the Magento install. Magento no longer sends HTML to shoppers. It only answers GraphQL queries from the React app. That means two deploy pipelines, two hosting setups and two things to monitor. The React app can live on its own subdomain or sit behind the same CDN as Magento.

  2. 02

    State managed via Apollo Client (queries + cache + mutations)

    Every piece of data on the storefront comes through Apollo Client, which sends queries to Magento’s GraphQL API and keeps a normalised cache in the browser. Apollo also handles updates after mutations like add to cart, login and place order. Getting that cache right on a large catalog takes real React experience. Get it wrong and the browser carries far more product data than it needs, or a shopper sees a stale price in the cart.

  3. 03

    Backend stays standard Magento 2: GraphQL is the only contact

    The Magento 2 install behind PWA Studio stays the same: same admin, same database, same attributes, same cron jobs. PWA Studio does not fork Magento. What changes is that shoppers never see Luma. Each page in the React app turns into one or more GraphQL queries to /graphql, and actions like add to cart, apply coupon or set shipping method become GraphQL mutations. So I look at GraphQL response times and caching first when a PWA Studio store feels slow.

  4. 04

    Magento Marketplace extensions need a Storefront-API-compat layer

    This is where most "let’s go headless" plans run into trouble. Most paid Magento extensions ship Luma .phtml templates and KnockoutJS components, and none of that renders in a React app. For each extension you need one of three things: a GraphQL schema and React components from the vendor, your own GraphQL resolver plus React component, or a replacement. Before I quote a PWA Studio build, I list every installed module and mark which group it falls in.

When to use it

Three scenarios where PWA Studio actually pays off

These are the cases where I would still recommend it. If your project does not match one of them, I usually point the store to Hyvä instead, because it is cheaper to build and much easier to maintain.

  • Multi-channel: native app + web from one Magento backend

    This is where PWA Studio makes the most sense. If a native iOS or Android app is actually planned and funded, and it will share the same GraphQL backend as the website, a React storefront lets the team reuse knowledge, components and API calls across both. If the app is only an idea for "later", I would not choose PWA Studio because of it.

  • Large stores with their own React team

    A PWA Studio storefront costs more to build and more to keep current than a Hyvä theme, so it only pays off on stores with enough revenue to carry that. The bigger question is people. You need React developers who know Apollo Client, GraphQL schema design and React performance, and you need them every month, not a few hours a week from a Magento agency.

  • Specific UX requirements that need full SPA control

    Prices that update live without a page refresh. AR or 3D product views. App-like page transitions and gestures. Offline browsing for shoppers on weak mobile networks. These need full control of rendering in the browser, which a server-rendered theme like Hyvä is not built for. If one of these is the main reason people buy from you, a headless build such as PWA Studio is worth the cost. For a normal catalog, cart and checkout, it usually is not.

Common mistakes

Four mistakes that turn PWA Studio projects into write-offs

Every one of these is preventable on day one. Most projects don’t prevent them, and the bill arrives in months 4-6.

  • Picking PWA Studio for a $5M GMV store

    The single most common, and most expensive, mistake. A $5M GMV store cannot support the cost structure of a PWA Studio build (~$80k+) plus its annual maintenance (~$50k+). Hyvä delivers 95% of the same performance + UX outcomes at 1/8 the cost. The rule: if "we want to be modern / future-proof / headless" is the only justification, you don’t need PWA Studio, you need Hyvä. PWA Studio earns its keep when you can name the specific multi-channel or UX requirement that Hyvä cannot deliver. If you cannot, pick Hyvä.

  • Underestimating React + GraphQL maintenance burden over 3 years

    Year-1 PWA Studio looks fine: the agency that built it is still around, the React version is current, the GraphQL schema is fresh. Year 2-3 is where the bill arrives: React 17 to 18 to 19 migrations, Apollo Client breaking changes, deprecated GraphQL fields, security patches, new PWA Studio releases that don’t auto-merge into your custom code. Plan for 15-25% of the build cost as ongoing yearly maintenance, and that is on top of the actual feature work. Most stores under-budget this by 2-3x and end up frozen on stale framework versions by year 3.

  • Forgetting that PWA Studio doesn’t auto-render server-side

    A naive PWA Studio install ships an empty HTML shell and hydrates everything in the browser via Apollo. Googlebot can usually handle this, but slowly, with a hydration delay, and with structured data that fires after the crawl budget runs out. SEO-critical stores need careful Apollo SSR (Server-Side Rendering) configuration: pre-rendering the cart, PDP, and PLP routes, hydrating with cached GraphQL responses, falling back to static HTML for crawlers. Many real PWA Studio implementations leak rankings during launch because no one budgeted the SSR work.

  • Assuming Magento Marketplace extensions just work

    They don’t. Most paid Magento extensions ship Luma PHTML + KnockoutJS, invisible to a React frontend. Your $400 product-feed extension, your $800 layered-nav extension, your $1,200 reward-points extension, all of them need vendor-provided GraphQL schemas + React components, or a custom compat layer you write yourself. Inventory every extension on day one, classify each as PWA-Studio-native / vendor-port-available / needs-custom-port / replace-with-equivalent. The audit takes 5-10 days and prevents the week-12 disaster where half the storefront is broken.

FAQ

Honest answers to the questions clients actually ask

Six answers covering cost, SEO, extensions, hosting, and Adobe’s long-term support story for PWA Studio.

  • PWA Studio vs Hyvä: which one should I pick?

    For 95% of Magento stores, Hyvä. Hyvä is server-rendered (Tailwind + Alpine on top of standard Magento PHP), launches in 4-12 weeks, costs $5-20k to build, costs ~$10k/year to maintain, and ships Lighthouse 95+ predictably. PWA Studio is a full React SPA on top of Magento GraphQL: 16-40 weeks to launch, $50-200k+ to build, $50-100k/year maintenance, variable Lighthouse 70-85. PWA Studio earns its keep only when you genuinely need a native mobile app sharing the same backend, $50M+ GMV justifies the multiplier, and you have a dedicated React team. If you cannot name those three reasons, pick Hyvä.

  • What is the cost differential at the same scope?

    Roughly 5-10x across both build and maintenance. A typical Hyvä build for a mid-sized store runs $5-20k; the equivalent PWA Studio build runs $50-200k+. Year-1 maintenance: Hyvä ~$5-15k, PWA Studio $50-100k+ (React expertise, GraphQL schema upkeep, Apollo cache tuning, service-worker debugging, ongoing React/Apollo/Webpack migrations). The cost gap doesn’t shrink over time: every new feature in PWA Studio costs more to ship and more to maintain. Across a 3-year ownership window, the all-in cost differential is closer to 8-10x.

  • What is the SEO impact of going headless with PWA Studio?

    It depends entirely on whether you configure Apollo SSR (Server-Side Rendering) correctly. A naive PWA Studio install ships an empty HTML shell and hydrates everything in the browser: Googlebot can usually crawl this, but with a hydration delay and risk of crawl-budget exhaustion on large catalogues. Proper SSR pre-renders critical routes (PDP, PLP, cart) with cached GraphQL responses, ensures structured data fires before hydration, and provides static-HTML fallbacks for crawlers. Done right, SEO is fine. Done naively (and most launches under-budget this) rankings drop for 2-6 months until SSR is fixed. Always budget SSR work into the build, not as an afterthought.

  • Will my Magento extensions work in PWA Studio?

    Most won’t out of the box. Standard Magento extensions ship Luma PHTML templates + KnockoutJS: invisible to a React frontend. Each extension needs one of: (a) vendor-provided GraphQL schema + React components (only ~10-15% of major extensions ship this in 2026), (b) a custom-written compat layer you build yourself, mapping the extension’s data to a GraphQL query, (c) replacement with a PWA-Studio-native equivalent, or (d) drop the extension entirely. Plan for 30-50% of your existing extensions to need rework. Inventory every extension on day one of the build and classify each before scoping the engagement: extension porting is the biggest source of unexpected cost in PWA Studio projects.

  • What are the hosting requirements for PWA Studio?

    Two separate hosting setups: one for the React frontend, one for the Magento backend. Frontend is typically Vercel ($20-200/month for production scale), Netlify (similar pricing), or self-hosted on AWS S3 + CloudFront ($50-500/month depending on traffic). Backend stays as standard Magento 2: Adobe Commerce Cloud, AWS EC2 / ECS, or any Magento-supported PHP host. Add Redis or DynamoDB for session storage if you split frontend/backend domains. Total monthly hosting bill for a mid-sized PWA Studio store typically runs $300-800, vs ~$150-400 for the equivalent Hyvä store on a single host. Not a make-or-break difference, but it is one more line item.

  • What is Adobe’s long-term support story for PWA Studio?

    Honest answer: weakening. PWA Studio was Adobe-promoted heavily 2018-2021 as the future of Magento storefronts. Adoption peaked 2021. Hyvä took mindshare from 2022 onwards: Adobe’s own 2025 keynote recommended Hyvä as the default starting point for new Magento builds. PWA Studio is still maintained, still gets updates, still works in 2026, but it is community-maintained more than Adobe-driven now, and the centre of gravity has clearly moved. New builds in 2026 should treat PWA Studio as "the answer for specific multi-channel use cases" rather than "the default modern Magento storefront". Existing PWA Studio stores are not in immediate trouble, but should plan their next major migration with eyes open.

Decision time

PWA Studio or Hyvä? Run the maths properly.

Side-by-side stack scorecard, 6-row comparison, 5-step decision flow, and the cost-of-ownership numbers across a 3-year window. Most stores discover Hyvä was the right call once the question is asked out loud.