Alberto Vena

Alessandro Desantis

First, a disclaimer: this is NOT a feature recap. If that's what you're looking for, Shopify's [Editions site](https://www.shopify.com/editions/winter2026) is the place to be. Instead, what we're doing here is what we've done with every Edition for the last few years: analyzing what these updates actually mean for upper-midmarket and enterprise brands, where Shopify created genuine value, and what they could have done better.

In the Winter 2026 Edition specifically, AI stole the spotlight. Sidekick now generates admin apps! It generates theme sections! It supports Skills and third-party integrations! If you read the product announcements, it all feels like success is just one carefully engineered prompt away.

And truth be told, there is substance behind the hype. Shopify Magic, and Sidekick specifically, are powerful tools that are only getting more powerful. Agentic Storefronts are putting every Shopify brand in front of hundreds of millions consumers using LLMs to shop, all with a click of a button. And much-needed infrastructure improvements and platform additions (e.g., A/B testing and theme rollouts) are making life easier for merchants, developers, and consumers.

But when you evaluate these evolutions through the lens of an upper-midmarket brand moving serious volume, there are some nuances to consider. In this article, we're going to talk about those nuances, highlighting some of the biggest opportunities that still lie ahead for the Shopify ecosystem.

## Sidekick's Code Generation Is Powerful But Requires Governance

Sidekick's code generation capabilities, for both themes and custom apps, represent an interesting leap forward in operational velocity, but they're not the cure-all some industry pundits are making them out to be.

In our experience, Sidekick excels at rapid theme prototyping. It gets you to about 80% visual accuracy fast, which is valuable when testing concepts or exploring ideas quickly. But when you think about long-term maintenance, you'll run into challenges such as:

- Excessive configuration options for settings that you'll never use.
- Isolated CSS and JavaScript that doesn't use existing utilities or patterns.
- No consideration whatsoever for the build system used by your theme (if any).

Admin app generation comes with similar benefits but also similar challenges.

The app store is littered with low-quality apps solving simple problems for $9.99/month, and we're all happy to see a few of those go away. If merchants can generate custom solutions they actually own, that's a genuine win.

But without a clear governance framework, your stakeholders will start generating apps that solve very similar problems in very different ways, with no consideration of existing patterns or cross-app interactions. As this functionality expands to storefront-facing features, which seems inevitable given the direction Shopify has taken with AI code generation, the stakes will get even higher. While admin apps affect operational efficiency, storefront apps affect revenue.

Moving forward, we'd like to see Shopify invest not just in AI code generation, but also in stronger primitives and better development guidelines that guide the AI, so it can be more considerate of its surroundings and the long-term impact of its output. Shopify should also educate its merchants on proper stewardship of AI-generated functionality, helping them answer questions such as:

- Which challenges are good candidates for AI-assisted solutions and which are not?
- How do we ensure that generated code integrates with existing patterns rather than creating islands of functionality?
- When should we hand off an AI-generated solution to our engineers for polish and maintenance?

At Nebulab, we're starting to establish such processes with our clients and getting the best of both worlds: the speed of AI prototyping combined with the discipline of human oversight and integration.

Without clear handoff processes and governance frameworks, you accelerate the accumulation of technical debt rather than evolution of your store.

## Sidekick's Data Analysis Lacks Integration

Sidekick's business intelligence capabilities now come in two forms: the conversational chatbot that answers questions about your store data, and the new Pulse feature where Sidekick proactively suggests business initiatives. Unfortunately, both face the same fundamental limitations around data access and context.

For a $5M brand with a small team and straightforward operations, these tools can provide valuable direction. The suggestions might be generic, but generic advice often works when you're just starting out, your business model is simple, and your data lives primarily within Shopify.

For a $50M operation managing 1,500 SKUs across wholesale, marketplaces and DTC, coordinating 60 employees, and balancing a multi-year positioning shift against quarterly revenue targets, the calculus changes entirely. At this scale, context matters _a lot_. Generic optimization suggestions that ignore your specific constraints only create noise that your team has to filter through.

Sidekick can't tell you whether increasing email frequency will increase sales or damage your brand perception. It can't factor in that your warehouse is already at capacity and can't support that new sales channel. It doesn't know that your bestselling product line is being phased out next quarter and you should start weaning customers off of it.

More fundamentally, Sidekick is limited to the data that Shopify has. For businesses that integrate data from ERPs, warehouse management systems, customer service platforms, marketing attribution tools, and financial systems, Sidekick's view is necessarily incomplete. It sees transactions and customer behavior within Shopify, but lacks the full picture.

This is our problem with platform-specific chatbots and agents: they all only have a small piece of the truth and a small set of all the tools they could use, which prevents them from orchestrating larger business processes.

While Shopify is nice for smaller brands, we'd also like to see Shopify invest in better data portability—through official partnerships with ETL providers, data warehouses, BI tools, and external LLMs—so that the data can be integrated as part of larger operational workflows. Give enterprises the ability to bring Sidekick's analytical capabilities into environments where it has access to the full context, not just Shopify's limited view.

Without that broader integration, Sidekick is useful for surface-level insights but inadequate for strategic decisions.

## SimGym and A/B Testing: A Missed Opportunity

Shopify launched two experimentation features in the Winter '26 Edition: native A/B testing and SimGym.

Native A/B testing is new and useful. You can now natively split traffic between theme variations and measure performance differences directly within Shopify. For smaller brands without dedicated experimentation infrastructure, this means you don't have to use external experimentation platforms and lowers the barrier to entry significantly (although you will still need enough traffic to power your tests).

Still, we were disappointed that Shopify didn't launch an API that other tools could ubuild upon, like they did for example with the Subscriptions API. Instead, external A/B testing solutions will continue to use the same client-side hacks they've always relied on.

This is a shame because large-scale brands doing serious experimentation (multiple treatments, custom metrics, audience exclusions) will never be able to use Shopify's native A/B testing. Allowing third-party tools such as Shoplift or Intelligems to build upon Shopify's offering would have dramatically improved the experimentation experience for merchants (through a more seamless experience) and consumers (through faster page loads).

In addition to native A/B testing, Shopify launched SimGym, which takes a very different approach: rather than testing with real users, it uses AI to generate synthetic user behavior and predict experiment outcomes. The concept is interesting: in theory, brands could use synthetic data to run tens of experiments and move iterate much faster on their UX.

Unfortunately, research from Nielsen Norman Group and other UX practitioners has found that [synthetic users exhibit idealized behavior](https://www.nngroup.com/articles/synthetic-users/), lack the messiness of human decision-making, and produce overly optimistic results. AI-generated participants are overly agreeable and to miss the contextual nuances that shape actual behavior. In short, they're unreliable for concept testing and business decisions.

This may be a bit far-fetched, but we think Shopify missed a broader and much more interesting opportunity here.

Instead of generating synthetic predictions, imagine if Shopify had opened its A/B testing framework to third parties and then systematically collected and surfaced anonymized data about tests across its entire merchant network. With enough context about the business and the ability for the AI to understand what's being tested (i.e., not just surface metrics, but the strategic intent behind the test) Shopify could offer an invaluable best practices playbook to smaller brands and a sophisticated A/B testing engine to larger ones.

For example, a brand testing a new product page layout could receive insights like: "Among premium skincare brands with AOV above $75, similar layout changes increased conversion by 8-12% when combined with trust signals, but decreased conversion by 3-5% when the change removed product ingredient details." That's actionable intelligence grounded in real behavior seen in similar contexts.

This would have been a win-win-win for Shopify, third-party A/B testing apps, and merchants. The data would have been much more reliable than synthetic predictions and it would have been a true competitive moat for Shopify—proprietary insights that no other platform could match. Instead, we got synthetic predictions of uncertain value and a basic testing framework that doesn't serve the needs of more sophisticated merchants.

## Whatever Happened to Hydrogen?

Clearly, Hydrogen is not a focus at Shopify anymore.

If you haven't followed the story, Shopify has made some big moves in the headless space between 2021 and 2024:

- In 2021, they launched Hydrogen, their React-based framework for headless commerce experiences, and Oxygen, their platform to host Hydrogen storefronts.
- In 2022-2023, they acquired Remix and used it to rewrite Hydrogen from scratch, positioning it as a major advancement in their headless commerce strategy.
- In 2024, they announced the Hydrogen Visual Editor, an entry-level alternative to more sophisticated solutions like Sanity and Contentful.

At some point around 2024, Shopify quietly started shifting their focus from headless commerce to AI as the next big thing:

- Hydrogen's GitHub repository has seen minimal activity in the last few months. Most of it was API version updates and dependency maintenance
- The Hydrogen Visual Editor never made it past the early access phase. As far as we can see, the initiative was killed before seeing the light of day.
- The Winter 2026 Edition includes exactly _zero_ Hydrogen announcements.

Our own conversations with Shopify sources confirmed our suspicions: Shopify is discouraging brands from going headless unless they have a very strong reason to do it. In fact, they are telling Hydrogen brands to move back to Liquid.

This is not the disaster it seems. Hydrogen has always been plagued by a number of problems, most of them tied to the dynamics of the Shopify and JavaScript ecosystems rather than the framework itself:

- Most of Shopify's app ecosystem assumes that merchants use Liquid. Brands using Hydrogen often need to implement their own integrations (assuming the tool they're integrating with is kind enough to offer an API).
- While Hydrogen offers an excellent developer experience, the JavaScript ecosystem is famous for being extremely fragmented. It was not uncommon for development teams to ignore Hydrogen in favor of their preferred framework.
- Most Shopify product announcements would make it into Liquid way before making it into Hydrogen, which was a source of endless annoyance.

None of this is to say that you shouldn't go headless, if your brand is complex enough to need it. But you should know that, in 2026, headless is not the default choice anymore. Before going off the beaten path, make sure you have evaluated the pros and cons of doing so. We'll publish a much deeper dive about this in the next few weeks!

## Where To Focus Your Attention

If you're running an upper-midmarket brand, here's what actually matters from this release:

- **Use Sidekick for rapid prototyping**, but establish clear handoff processes before your team generates a dozen isolated apps solving similar problems in different ways. The speed is real, but so is the technical debt if you don't have governance in place.
- **Double check the AI's insights.** Sidekick is useful for quickly extracting raw numbers from Shopify, but it still hallucinates every now and then and it lacks important context about your business. Don't any results or conclusions at face value.
- **Adopt native A/B testing if you're only starting out**. It's a solid foundation for brands just starting to build experimentation capabilities. If you're already running complex tests with custom metrics and audience segmentation, you'll still need third-party tools.
- **Ignore synthetic data**. Synthetic user predictions are interesting in theory but unreliable in practice. If you have the traffic, run real tests with real customers. If you don't have the traffic, stick to e-commerce UX best practices until you do!
- **When it comes to headless, thread lightly**. Shopify's investment has clearly shifted elsewhere. Unless you have compelling architectural reasons to go headless, the default path is Liquid.

As always, if you need help sorting through adopting the new features or understanding what they mean for your business, [let's talk.](https://nebulab.com/contact-us)


Shopify's Winter 2026 Edition: The Needle Movers and the Missed Opportunities

Massimiliano Lattanzio

Nicolò Rebughini

For a DTC brand, a well-designed customer portal directly impacts whether customers stay or churn. [Self-service portals can resolve 40-70% of support tickets](https://www.richpanel.com/blog/customer-self-service) without agent intervention, and customers using portals report [68% fewer delays](https://read.spryker.com/rise-of-self-service-portals-in-b2b-aftersales) compared to those relying on traditional support channels. When customers can manage subscriptions, track orders, update preferences, and handle returns without friction, they're more likely to stay engaged with your brand.

Unfortunately, the Shopify customer portal landscape is fragmented. You're choosing between three competing approaches—Shopify's native Customer Accounts with UI Extensions, app-provided portals from your subscription and loyalty vendors, or a custom-built solution. Each comes with different technical constraints, maintenance costs, and UX limitations. Choose the wrong approach, and you're either locked into a fragmented experience that erodes trust, or committed to a custom build that requires ongoing investment without clear ROI.

From our work building customer portals for mid-market and enterprise DTC brands, we've seen how this decision plays out. Below, we'll walk through each approach—what it offers, where it falls short, and which business models it actually serves—then give you a framework for choosing the right one based on your retention strategy, technical resources, and growth stage.

## Shopify's Native Approach: Low Maintenance, Limited Control

Shopify's Customer Accounts and Customer Account UI Extensions offer the most "Shopify-native" way to build a customer portal today. [Launched in January 2023 and opened to app developers in December 2024](https://gadget.dev/blog/understanding-new-customer-accounts-what-they-are-and-how-to-build-with-them-as-a-developer), this approach represents Shopify's strategic shift toward extensibility—the same philosophy behind Checkout UI Extensions. Instead of letting merchants hack together solutions with Liquid code and app embeds, Shopify is creating a controlled, composable environment where functionality comes from modular blocks.

This approach lets you extend Shopify's own customer account area by adding custom pages and blocks, either built by your team or provided by apps. You can mix native Shopify features—like order history, self-serve returns, and account details—with custom-built extensions that enhance the experience. Think of it as Shopify providing the foundation and letting you furnish the rooms.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/83b029500d7b7e40498513ec3986255954318df6-3054x1548.png?fit=clip">
  <caption>The Customer Account portal with some custom blocks</caption>
</figure>

**Pros:**

- **Shopify-native UX:** Your portal inherits Shopify's secure, modern interface and authentication system, including passwordless login via Shop Pay (already familiar to [150+ million users](https://www.shopify.com/blog/introducing-customer-account-extensions)).
- **Built-in functionality:** Includes order tracking, self-serve returns, and address management out of the box.
- **Easy integration with apps:** Apps that have built UI extensions plug directly into this framework with no custom integration work.
- **Lower maintenance overhead:** Less need to handle authentication, hosting logic, or security updates—Shopify manages the infrastructure.

**Cons:**

- **Limited design flexibility:** You're constrained by Shopify's layout and component structure. [You can't override CSS](https://shopify.dev/docs/api/customer-account-ui-extensions/latest) or create truly custom interfaces.
- **Incomplete app ecosystem:** This is the real challenge. While Shopify is clearly investing in this architecture, many apps still rely on legacy customer portals. If you're using Recharge for subscriptions, Yotpo for loyalty, and Loop for returns, you'll need to wait for each vendor to build UI Extensions—or accept that parts of your customer experience will still live outside this unified system.
- **Migration complexity:** If you're already using legacy app portals, switching to Customer Account UI Extensions means either convincing every app vendor to rebuild their integration or abandoning apps that won't migrate. This isn't a flip-the-switch upgrade.

**Best for:** Merchants who want a low-maintenance, secure, and scalable solution that stays aligned with Shopify's roadmap, and who can accept design constraints in exchange for reduced technical overhead. This works especially well if you're building a new store or using apps that have already adopted UI Extensions.

## App-Based Portals: Fast Setup, Fragmented Experience

Many Shopify apps—subscription managers like Recharge, loyalty programs like Yotpo, returns systems like Loop—offer their own customer portals. These can be embedded in your theme as standalone pages, theme blocks, or even full-page portals hosted by the app.

Each app manages its own UI and logic, often linking back to Shopify data via APIs. This approach is quick to set up and requires minimal coding, since most apps handle their own authentication and interface. For brands with a single dominant use case—say, a subscription business where 80% of customer portal activity is managing subscriptions—this can work well.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/6426d83b66f28ee54d2d46b860280e2a550c0651-3054x1992.png?fit=clip">
  <caption>An example of the Customer Portal offered by Loop, a popular returns app. Everything is configurable from the app itself, without the need for custom integrations</caption>
</figure>

**Pros:**

- **Fast and easy setup:** You can launch a customer portal experience within hours or days, not weeks.
- **Low technical overhead:** App developers handle updates, security, and UI improvements. You're essentially renting functionality.
- **Modular flexibility:** You can add or remove apps without major rework, though this comes with trade-offs (see cons).

**Cons:**

- **Fragmented experience:** This is the killer. Each app renders its own UI, often with different design patterns, navigation structures, and even login flows. A typical DTC brand using Recharge, Yotpo, and Loop might send customers to three different portals, each with different visual styles and interaction patterns. One might use a sidebar navigation, another a top nav, and a third might be a full-page takeover. **Your customer has to learn three different interfaces just to manage their relationship with your brand.**
- **Limited branding control:** Most app portals offer basic theming—colors, logos, fonts—but you can't deeply customize the layout or UX. You're working within the app's design system, not yours.
- **Customization challenges:** If you want to modify these experiences beyond what the app allows, you're either stuck or you're adding brittle workarounds (custom CSS injections, JavaScript hacks) that break when the app updates.

**Best for:** Brands that prioritize speed and simplicity over control, especially small to mid-sized stores using multiple apps that already provide customer-facing features. This is also a strong fit for brands with a single dominant use case—like subscription management—where one app portal handles 80%+ of customer needs and fragmentation is less of an issue.

## Custom Builds: Total Control, Ongoing Investment

The third option is to build your own custom customer portal, either as part of your Shopify theme or as a standalone web application.

This approach involves creating a bespoke interface that connects to Shopify's Storefront API, Admin API, or third-party app APIs. It can live within your existing theme or as a separate site (for example, a subdomain like `account.yourstore.com`) that shares your brand's design system.

For example, you might use Shopify's APIs to fetch customer order history, connect with Recharge for subscription management, integrate with a loyalty program through their API, and layer on custom features—all inside one unified dashboard that looks and feels like your brand.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/596588599489991f20af764f6fd490ad424dad89-3054x1992.png?fit=clip">
  <caption>The custom customer portal we built for Cometeer. It connects with Recharge APIs to manage subscription data and exposes several custom-built functionalities, including a bespoke coffee box management experience powered by their proprietary recommendation algorithm.</caption>
</figure>

Cometeer needed a custom portal because their business model demanded it. **They required a completely bespoke coffee box management experience that would leverage their custom recommendation algorithm—something no off-the-shelf app could provide.** They also found Recharge's out-of-the-box portal too slow and cumbersome for their customer experience standards. [Read the full Cometeer case study](https://nebulab.com/case-studies/cometeer) to see how a custom portal became a competitive differentiator.

**Pros:**

- **Total flexibility:** Design and implement every interaction, layout, and integration exactly how you want. Your portal becomes an extension of your brand, not a compromise.
- **Unified experience:** Bring data from multiple apps and systems into one branded interface. Your customer sees one cohesive experience, not a patchwork of app UIs.
- **Full ownership:** Control your roadmap, UI, and data flows. You're not waiting for app vendors to add features or fix bugs—you build what you need, when you need it.
- **Performance optimization:** You can optimize load times, interactions, and mobile experiences in ways that app-based portals don't allow.

**Cons:**

- **Higher development cost:** Building a custom portal requires significant upfront investment in design, development, and testing.
- **Integration complexity:** You depend on whether each third-party app exposes the APIs you need. You're betting that Recharge, Loop, or your other vendors will maintain stable APIs and won't sunset features you've built against.
- **Maintenance overhead:** Every API update, Shopify version change, or app deprecation can require adjustments. You need ongoing developer resources—either in-house or via an agency—to keep the portal running smoothly.

**Best for:** Brands with strong technical resources (in-house or via an agency) who see the customer portal as a strategic differentiator and want a fully unified experience across all post-purchase touchpoints. This is especially relevant for subscription businesses or brands with products that require rich after-care and ongoing customer education.

## How to Choose the Right Approach

Choosing how to build your customer portal comes down to balancing control, complexity, and cohesion. But more fundamentally, it comes down to how you think about retention.

If your products are typically one-time purchases with minimal post-sale engagement, you probably don't need a sophisticated portal. The app-based or Shopify native approach will serve you fine, and you can scale to nine figures and beyond with a standard experience.

But if you're running a subscription business, selling products that require ongoing education or support, or competing in a category where retention is the primary growth lever, then your customer portal is a retention engine, not just a commodity. In those cases, the investment in a custom or hybrid solution often pays for itself through reduced churn and increased lifetime value.

Here's a practical framework:

| Your Situation | Best Fit |
| --- | --- |
| You want to launch quickly with built-in features and minimal technical overhead | Shopify Customer Accounts + UI Extensions |
| You're using multiple apps, want minimal coding, and can accept some fragmentation | App-provided portals |
| You need a cohesive, fully branded experience and have technical resources | Custom-built portal |
| Your business model depends heavily on retention, subscriptions, or ongoing customer education | Custom-built portal |
| You want flexibility with lower maintenance than a full custom build | Hybrid approach (UI Extensions + custom theme work) |

In our experience, the app-based approach works well for early-stage brands or those with simple needs, but because of the poor and fragmented UX it creates for the customer, it's rarely a long-term solution for brands where retention is a primary growth driver 

## Your Portal Strategy Reflects Your Retention Strategy

As you've seen, there is no universally right approach to building your customer portal in Shopify:

-  Shopify's native Customer Accounts offer a secure, low-maintenance foundation that will get richer as Shopify continues investing in extensibility. 
- App-based portals provide speed and simplicity but often at the cost of fragmentation. 
- Custom builds deliver total control and unified experiences but require ongoing investment.

The right choice depends on your business model, your technical resources, and how central post-purchase experience is to your retention strategy. The only wrong answer is ignoring the decision until customer complaints force your hand.

If you're unsure which approach best fits your brand, or if you need help evaluating the trade-offs and implementing a customer portal that turns retention into a competitive advantage, [let's talk](https://nebulab.com/contact-us). We can help you design a customer account experience that delivers results and exceeds your customers' expectations.

Customer Portals in Shopify: Understanding Your Options

Replatforming is one of those moments that can either unlock a step-change in organic growth—or erase years of SEO equity overnight. 

A new commerce stack can improve speed, flexibility, and long-term maintainability. It most likely also breaks URL structures, buries content, and confuses search engines at scale. A 20–40% traffic dip in the first months after launch isn’t unheard of when fundamentals are missed, and the revenue impact can be painful. The upside, though, is equally real: treat SEO as a first-class citizen throughout the migration and you can come out with faster pages, cleaner architecture, and a stronger growth engine than you started with. 

As we repeat as a mantra, and it applies to every aspect of a migration, especially with SEO, to try to change as few things as possible during the migration, and patiently wait until the improvements are easy and safe to implement.

This guide blends hard-won lessons from complex e-commerce migrations with practical checklists you can use right now. We’ll cover the technical foundations *and* the organizational dynamics that make or break replatforms. Because SEO fails less often in code editors than in project plans.

## Pre‑Migration Audit & Benchmarking

### Establish a Baseline Before You Move Anything

If you can’t describe exactly how your site performs today, you can’t diagnose what changed tomorrow. Start with a thorough SEO audit and a shared benchmark doc that the stakeholders agree to protect.

At minimum, benchmark:

- **Traffic & revenue baselines:** Segment by channel (organic/non-brand vs. brand), device, market, and key templates (home, category/PLP, product/PDP, content hubs, blog, help center). Tie organic sessions to revenue where possible.
- **Rankings and visibility:** Track head terms and long-tail queries per template, Capture average ranks and note which terms drive conversions.
- **Crawl data & index footprint:** Export from your crawler and Google Search Console. Inventory indexable vs. non-indexable pages, canonicalized duplicates, parameterized URLs, pagination, and index bloat.
- **Top-performing pages and link equity:** Identify the top 10–20% of URLs that drive 80% of organic value. Map internal links to these pages and log external links you must preserve.

Document technical debt you plan to fix on the new stack: render-blocking scripts, slow templates, thin content, overlapping intent, and legacy parameters. Include dates on every report to ensure post-launch comparisons are apples-to-apples.

## URL Mapping & Redirect Strategy

### One-to-One Redirects Are Non‑Negotiable

Your URL structure is your site’s skeleton. Change it without a precise redirect plan and the body collapses. For any URL that changes, implement **one-to-one 301 redirects** from the old canonical to the new canonical. Avoid chains and loops; every additional hop dilutes signals and slows users down.

**Homepage and category dumps are rank-killers.** Blanket-redirecting old PDPs to the homepage (or to their parent category) is a fast path to irrelevance. Search engines treat irrelevant redirects like soft 404s—you don’t preserve equity, and users bounce because intent isn’t met.

### Practical Tips for Redirect Excellence

- **Build the map early.** Start from your top-value URLs and work down. Include query parameters that resolve to unique content (e.g., `/size=xl` may be ignorable; `/color=navy` may map to a canonical color page if that’s how your new platform works).
- **Normalize everything.** Decide on trailing slashes, case sensitivity, and default file extensions. Enforce consistently to prevent duplicate paths.
- **Keep UTMs safe.** When implementing your redirects, be sure you are not removing UTMs (or any other query params) from the URLs, otherwise you might compromise attribution tracking.
- **Test before launch.** Validate your redirect file in staging with a crawler. Check for 200/301/404 distributions, chains, loops, and relevancy (old product → closest new product or guide).
- **Deploy at the edge.** If possible, run redirects at your CDN/edge layer for speed and reliability.

### Treat Content as the Oxygen of SEO

During migrations, content gets “cleaned up” or rewritten. That can be good—but accidental pruning is common. Titles, H1s, product descriptions, and alt text are easy to strip when templates change. Structured data is often left behind or auto-generated with gaps. If there are content mistakes that can be addressed along with the migration, stop doing it and take a note for later. Again, it’s better not to change too many things together; otherwise, it will be hard to understand where SEO issues originate. 

### What to Preserve—and Improve

- **Metadata parity:** Ensure title tags, meta descriptions, H1s, and canonical tags carry over. Where templates change, confirm variables resolve correctly (e.g., brand + model + key attribute).
- **On-page copy and attributes:** Preserve unique product copy, comparison tables, FAQs, and reviews. Standardize units and naming conventions to avoid duplicate content from near-identical variants.
- **Media and alt text:** Maintain image URLs where feasible, or redirect them. Keep descriptive alt text for accessibility and image search.
- **Structured data:** Recreate JSON-LD for Product, Breadcrumb, Review, Article, FAQ, and Organization. Validate with Google’s Rich Results Test and ensure parity with visible content.

**Manual review is mandatory.** Pick the top 50–200 URLs by organic value across templates and review them page-by-page in staging. Look for lost copy chunks, missing schema, and new UX that hides or defers critical information. If something feels “lighter,” it probably is.

## Technical Considerations

### Replatforming Is a Chance to Upgrade, Not Just Replicate

Perfect preservation isn’t realistic. Your new platform will bring its own SEO opinions, often better than what you had before, and some of them are non-negotiable. Shopify’s URL structure, as an example, is fixed. That’s not a threat; it’s a constraint you can leverage. Treat these standards as a built-in upgrade path: use the move to clean up crawl paths, modernize rendering, and lift Core Web Vitals where possible. The key here is balancing touching only things that have a real impact or are in a no-risk zone. Some examples:

**Robots & index controls:**

- Align **noindex** and **canonical** rules to your new architecture. If you consolidate filters or change pagination, update rel=“prev/next” strategies and canonicals accordingly.

**Sitemaps:**

- Generate clean, modular XML sitemaps (≤50k URLs per file) by template and locale. Exclude noindex/redirecting/404 URLs. Host them on the primary host and reference them in `robots.txt`.

**Rendering & performance:**

- Prefer SSR or SSG for content-critical templates; hydrate interactivity progressively. Ensure your SPA routes are indexable and expose canonical, meta, and schema on initial HTML;
- Use the migration to improve **Core Web Vitals**. Compress and lazy-load media, reduce JS bundle size, and adopt modern image formats. Measure template-by-template rather than sitewide averages.

**Internationalization:**

- If you operate in multiple locales, validate `hreflang` across the new structure. Misaligned language-region pairs or missing return tags can throttle international visibility.

## Pre‑Launch Testing

### Treat Staging Like Google

Your staging environment is where good intentions meet reality. Crawl it with enterprise-grade tools and with Googlebot-like settings. The goal: catch anything that could impair discovery, understanding, or measurement. 


> In Shopify, crawling a store has been historically a problem, as the platform was failing to distinguish genuine and controlled crawls and malicious bots. They recently released an update to allow SEO specialists to use [Web Bot Auth](https://datatracker.ietf.org/doc/html/draft-meunier-web-bot-auth-architecture) to authorize tools to crawl the website and complete audits. 

**What to QA before launch:**

- **Canonical tags:** Are they self-referential and stable? Watch for environment URLs sneaking into canonicals.
- **Meta and headers:** Confirm `noindex`, `nofollow`, and caching headers are correct by template.
- **Structured data:** Validate JSON-LD at scale. Check Product offers/prices/availability match the page.
- **Internal links:** Ensure navigation, breadcrumbs, related products, and in-content links point to production paths (not staging) and use consistent trailing slash rules.
- **Pagination & filters:** Verify canonical strategies and indexability of facets. Decide which filters deserve indexation and which should be `noindex`.
- **Analytics & tags:** Confirm GA/GTM (or your stack), conversion events, and ecommerce schema fire correctly. Deduplicate events to avoid inflated revenue.
- **Sitemaps & robots:** Generate production sitemaps from staging, then disable staging in `robots.txt`. Dry-run the production `robots.txt` to avoid surprises.

## Post‑Launch Monitoring

### The First 4–6 Weeks Are the Danger Zone

Launch day isn’t the finish line; it’s when the real work begins. Search engines will revisit, recrawl, and reinterpret your site. Tiny issues can compound into big problems if you’re not watching closely.

**Daily (and weekly) checks:**

- **Crawl errors:** Monitor 404/5xx spikes in logs and Search Console. Prioritize legacy URLs with external links.
- **Redirect health:** Watch for chains and high-latency routes. Patch mismapped redirects quickly.
- **Indexation & coverage:** Track valid vs. excluded pages. Investigate sudden swings in “Duplicate, Google chose different canonical” or “Crawled – currently not indexed.”
- **Rankings & traffic:** Compare to pre-migration baselines by template and market. Watch non-brand first—brand often masks issues.
- **Sitemaps:** Ensure new URLs are submitted and rising in “Indexed” count. Remove retired sitemaps.
- **Core Web Vitals:** Check for regressions by template. Tracking scripts and A/B tools often bloat JS unexpectedly.

## Ongoing Optimization

### The Migration Is the Beginning of a New SEO Cycle

With the new stack live, resist the temptation to “set and forget.” The best-performing teams set a 90-day post-launch roadmap to convert the migration into momentum.

Focus on:

- **Internal linking refinement:** Use crawl and click data to push equity toward high-value pages—new collections, seasonal hubs, or evergreen guides. Revisit nav and breadcrumbs with real user behavior.
- **Backlink reclamation:** Outreach to update important external links that still point to redirected URLs. Every updated link removes a hop and strengthens relevance.
- **Content re-optimization:** Compare pre- and post-launch rankings. Refresh thin or underperforming pages. Expand FAQs based on emerging queries. Build content around new capabilities the platform unlocks (e.g., better comparison components or dynamic bundles).
- **Schema enrichment:** Add missing structured data types and test eligibility for new SERP features.
- **Technical hardening:** Keep pruning parameter cruft, improve caching, and continue shrinking JS. Treat Core Web Vitals budgets as part of your web performance SLOs.

## Final Takeaway: Paranoia and Precision Protect SEO

Replatforming is equal parts engineering project and change-management exercise. The teams that win keep SEO at the table from discovery to post-launch, blend caution with ambition, and treat baselines as a contract with the business. Precision in redirects, content parity, and technical configuration prevents avoidable losses. Paranoia—healthy skepticism and relentless verification—catches the edge cases that otherwise compound.

Most importantly, view replatforming as the start of a stronger SEO engine. Take advantage of all these tasks to clearly understand what’s needed to fix crawl waste, speed up templates, consolidate content, and build richer experiences once you are on the other side. Done right, you won’t just protect your rankings—you’ll future‑proof your visibility and open new lanes for growth.

If you’re planning a replatform or recovering from one and want an experienced partner to guide the process, **let’s talk**: [https://nebulab.com/contact](https://nebulab.com/contact).

How to Ensure SEO Integrity During a Replatform

It's that time of the year! After spending considerable time going through [Shopify's Summer 2025 Edition](https://www.shopify.com/editions/summer2025) and experimenting with some of the features that became available over the last few months, we are excited by the platform's latest releases: Shopify continues to push the boundaries of what's possible in e-commerce, with remarkable new features and expanded capabilities.

Still, while the overall direction is encouraging, we've also identified some implementation challenges, particularly for the type of mid-market and enterprise client we serve.

Let's take a look at what's changed, what it means for developers and merchants, and where we think Shopify should focus next!

## Horizon: Who's Thinking About the Developers?

![](https://cdn.sanity.io/images/kqgmf0g2/production/2c1d263d8905534742e7b134c45f61f38d02d978-800x450.webp?fit=clip)

[Shopify's new Horizon theme](https://www.shopify.com/news/summer-25-edition-merchant) created a lot of excitement, especially with the no-code/low-code crowd: with the new nested blocks and [AI-powered block generation](https://www.shopify.com/blog/expanding-your-ai-horizons-summer-edition-25), merchants have more flexibility than ever.

While we appreciate all the love that went into [Horizon](https://themes.shopify.com/collections/horizon-themes), our team also had some concerns:

- "What happens to Dawn now?" was the recurring question. With Horizon being the new standard, we expect Dawn to be left behind, forcing agencies and merchants to adjust.
- As most developers learn at some point, giving non-technical users more content management flexibility often comes at the expense of UX and brand consistency. Could Horizon be _too_ flexible for a merchant's own good?
- While Horizon is great, it primarily addresses Shopify's SMB merchants. Meanwhile, developers still need to build custom CI/CD pipelines if they want a robust theme management workflow.

The Shopify theme ecosystem is already renowned for its friendliness towards non-technical users. As Shopify gains traction in the mid-market and enterprise segment, we were also expecting the platform to invest in more robust primitives, tooling, and workflows for theme development—especially since larger merchants are increasingly choosing Liquid over headless in an effort to simplify (more on this below).

As an example, an improved GitHub integration could streamline theme development significantly, and it would be the perfect complement to Shopify's marketing- and simplicity-centered narrative.

## Markets: Segmentation Evolves Beyond Geography

![](https://cdn.sanity.io/images/kqgmf0g2/production/4224e88863540e39b12e9556cf23fbba6c15ba13-1280x720.jpg?fit=clip)

With the latest updates, Shopify has turned Markets from an internationalization tool into a more comprehensive segmentation platform. Merchants can now [segment markets by customer type (B2C vs. B2B), geography and channel (online vs. retail)](https://www.shopify.com/blog/markets), all from a unified interface.

However, despite the new experience finally putting an end to the discrepancies between B2B, POS, and the old Shopify Markets, we also think there's room for improvement:

- The new Markets interface requires a learning curve—the parent-child market relationships aren't immediately intuitive, which is understandable given the complexity of the problem Shopify is solving.
- While Shopify has fixed a number of bugs related to Markets and New Customer Accounts, some were left unaddressed. As an example, the "Buy Again" button still defaults to your primary market rather than the purchase market.

We're also a little concerned by the state of the ecosystem around Shopify Markets: in our experience, very few third parties are able to integrate with Markets at the moment.

Alberto from our team raised an important consideration: "With the new Markets, the ecosystem will need time to align. It took three years for some apps to start supporting the current Markets architecture, and these updates may require them to redo some of the work."

## Next-Gen Dev Platform: So Far So Good

![](https://cdn.sanity.io/images/kqgmf0g2/production/1a7cee517c85cff09117135aa8d89a57347ac715-800x450.webp?fit=clip)

[Shopify's next-gen developer platform](https://shopify.dev/beta/next-gen-dev-platform) shows real promise, with local development capabilities, declarative metaobjects/metafields definitions, monitoring and logging, and much more.

The direction is encouraging, even though some core challenges remain:

- The new localhost architecture is exciting and could really speed up the development of custom apps. Unfortunately, it doesn't support webhooks or Shopify Flows yet—both of which we use heavily. We do recognize these are tough problems to solve, but we're also confident Shopify can figure them out!
- Declarative data definitions are an interesting solution to the ancient problem of Shopify schema management. However, because the resulting metaobjects and metafields are app-owned, they can't be used across different apps, which is problematic in large builds where merchants have multiple custom or third-party apps that need to be integrated.
- The [unified Polaris Web Components](https://shopify.dev/beta/next-gen-dev-platform/polaris) are incredible, but will require yet another migration. Alas! At least there's [an MCP server](https://github.com/Shopify/dev-mcp) to help with the job.

As we excitedly wait for the next batch of improvements, we'll continue to complement Shopify's built-in capabilities with some of our custom tooling, such as [Shopify Toolkit](https://github.com/nebulab/shopify_toolkit).

### AI: One MCP Server to Rule Them All

![](https://cdn.sanity.io/images/kqgmf0g2/production/f98633309e66df5cc87c4530e5fee392ddf07c81-2840x2130.webp?fit=clip)

Quite frankly, the early iterations of Shopify Sidekick were underwhelming to say the least: the agent would hallucinate more often than not, unable to answer even the most basic queries.

Today's version tells a different story entirely. With sophisticated reasoning capabilities and deep platform integration, [Sidekick](https://www.shopify.com/blog/expanding-your-ai-horizons-summer-edition-25#3) now delivers usefulinsights on conversion metrics, bounce rates, and sales performance, and can even take action on behalf of the merchant. While we don't see larger brands dropping more sophisticated analyticsa and BI tooling for Sidekick, it is undeniably come a long way.

But Shopify is not using AI just for operational efficiency. With Perplexity, ChatGPT, and Google all recently announcing their AI shopping features, the platform is investing heavily in standardized and interoperable data access. As a couple of examples:

- The [Global Catalog](https://changelog.shopify.com/posts/introducing-shopify-catalog) allow LLMs to retrieve structured, real-time catalog access optimized for AI consumption. Also, Global Cart and Checkout should be launching soon, allowing LLMs to enable end-to-end conversational checkout experiences.
- The [Storefront](https://shopify.dev/docs/apps/build/storefront-mcp/servers/storefront) and [Customer Accounts](https://shopify.dev/docs/apps/build/storefront-mcp/servers/customer-account) MCP servers open new possibilities for AI-driven shopping experiences: think a wine sommelier chatbot with full inventory awareness and transactional capabilities.

While most of these products are in their very early stages, we'll keep experimenting over the next weeks and months to get a sense of all the potential use cases, so stay tuned!

## The Road Ahead

While this Edition was impressive as always, here's _what else_ we would have liked to see but didn't!

### Search & Discovery Needs Some Love

First of all, Shopify's Search & Discovery continues to lack advanced capabilities:

- Empty collections appear prominently in search results with no built-in way to hide them, creating a poor user experience that directly impacts conversion rates, especially for international merchants that might only sell certain collections in specific markets.
- The inability to use metafields for search indexing forces merchants into awkward workarounds—like copying metafield data into product descriptions just to make it searchable.

When merchants invest heavily in rich product data through metaobjects and metafields, that investment becomes worthless if customers can't discover products through that enhanced information.

As a result of some of these issues, one of our clients recently switched back to their custom search solution after finding Shopify's native search inadequate for their catalog complexity.

For a platform now positioning itself as enterprise-ready, we're hoping to see more investment flow into Search & Discovery to fully integrate it with the rest of Shopify's ecosystem.

### Whatever Happened to Hydrogen?

Perhaps the most interesting omission from the Summer 2025 Edition was the near-complete absence of Hydrogen updates, which might seem even more puzzling considering how much attention it has received in [Summer '24](https://nebulab.com/blog/shopify-editions-summer-2024) and [Winter '25](https://nebulab.com/blog/shopify-boring-edition).

However, given what we're seeing in the market, we were not too surprised that Hydrogen is taking a backseat: the reality is that most brands are currently choosing Liquid themes over headless solutions, prioritizing simplicity and reliability. Even brands that initially launched on Hydrogen are migrating back to Liquid themes, finding that the promised flexibility doesn't justify the additional overhead in the current economic climate.

To be fair, Shopify did release [Storefront Web Components](https://shopify.dev/docs/api/storefront-web-components), allowing merchants to embed the Shopify experience off-site and anywhere they can use HTML—we have some demos coming soon!

All in all, we're confident that we'll see more news about Hydrogen in the upcoming months, but for the time being, the market—and Shopify with it—have focused elsewhere.

## What This Means for You

Shopify's Summer 2025 Edition brought meaningful progress, although some annoying gaps persist. While we expect Shopify's future updates to address some of these pain points, brands should also strive to understand what Shopify does exceptionally well and where additional investment may be necessary to meet their specific business requirements.

At Nebulab, we're excited to help clients leverage these improvements while building complementary solutions where needed. If you need any help integrating Shopify into your business, [don't hesitate to reach out!](https://nebulab.com/contact-us)

Beyond the Horizon: An Honest Take on Shopify’s Summer 2025 Edition

Last week, Shopify released their [Winter '25 Edition](https://www.shopify.com/editions/winter2025), aptly named “The Boring Edition.” Despite containing over 150 updates, the Winter '25 Edition contains very few new features, but rather a broad sweep of improvements touching everything from checkout to developer tools.

And honestly, we couldn't be happier about it.

While Shopify’s pace of innovation has delivered powerful new capabilities like Markets, Customer Accounts, and POS over the past few years, it has also created complexity within their ecosystem. Each new feature brings its own set of integration challenges and edge cases.

For merchants operating at scale, these seemingly minor compatibility issues can cascade into significant operational hurdles. Even when individual challenges have workarounds, the cumulative effect of managing multiple partial solutions creates friction in day-to-day operations.

By following up the Summer '24 Edition (“Unified”) with one that’s even more focused on stability, Shopify demonstrates a clear commitment to addressing these foundational challenges. This approach is particularly crucial as they continue expanding their enterprise presence, where system reliability and seamless integration are non-negotiable requirements.

Let’s explore how these improvements work together to create a more robust platform for enterprise commerce.

## Product Management and Discovery: Enhanced Control and Visibility

At the heart of any e-commerce operation is the product catalog, and this release brings several improvements to how merchants can manage and present different types of products.

Key updates include:

* Combined Listings now allows merchants to [choose if parent or child products should appear in search and product recommendations](https://www.shopify.com/editions/winter2025#configure-combined-listings-for-search), providing better control over catalog presentation.
* Bundles have been significantly improved with [new analytics](https://www.shopify.com/editions/winter2025#reporting-for-bundles), [more consistent presentation](https://www.shopify.com/editions/winter2025#a-clearer-view-of-bundles) across admin and customer touchpoints, and [accurate inventory status](https://www.shopify.com/editions/winter2025#accurate-bundle-inventory) when using fulfillable inventory.
* Subscription management has also been enhanced with [oversell protection](https://www.shopify.com/editions/winter2025#oversell-protection-for-subscription-renewals), ensuring renewals respect inventory settings and preventing out-of-stock issues.

All of these improvements aim at consolidating and improving interoperability between different features of the platform, making life easier for larger and more sophisticated merchants. We have run across several of these limitations in our own work in the past, so we’re glad to see them being addressed head-on.

## Checkout and Payments: More Flexibility and Customization

Building on the enhanced product management capabilities, Shopify has also made significant strides in making the checkout process more flexible and customizable.

Notable updates include:

* [Split shipping](https://www.shopify.com/editions/winter2025#split-shipping-now-available) is now available to all merchants, allowing customers to choose different shipping methods for different parts of their order when items will be fulfilled separately. This is critical for marketplaces, where the same order may be fulfilled by multiple vendors.
* [Checkout Blocks is now available on the thank you and order status page](https://www.shopify.com/editions/winter2025), and [chat apps can now hook into the checkout flow.] This unlocks completely new capabilities and customer touchpoints, and we can't wait to take the new customization APIs for a spin!

Checkout is an area where Shopify has historically been very restrictive. However, they have been opening up more and more customization APIs over the last couple of years, allowing merchants to build their own customizations without relying on ugly workarounds. We expect this trend to continue, enabling new use cases and further reducing the effort of checkout customizations for Shopify merchants across the board.

## Global Commerce and Compliance: Expanded International Capabilities

As merchants continue to expand globally, Shopify has introduced several features that make international selling more manageable and compliant.

This release brings significant improvements for merchants operating internationally:

* Semantic Search [is now available in more languages](https://www.shopify.com/editions/winter2025#natural-search-in-more-languages), allowing customers worldwide to search using natural, everyday language. While Shopify's native solution cannot compete with more robust paid offerings, it's an excellent starting point for brands looking to elevate their search experience—and now, it's available to even more merchants!
* Shopify Tax [has expanded to the EU and UK](https://www.shopify.com/editions/winter2025#shopify-tax-in-the-eu-uk), offering automated VAT compliance including automated calculation and [VAT invoice generation.](https://www.shopify.com/editions/winter2025#vat-invoices-with-shopify-tax) 
* [Customer account extensions](https://www.shopify.com/editions/winter2025#customer-account-extensions) have finally entered general availability, allowing merchants to customize the New Customer Accounts UI with proprietary and third-party apps. We’ve been using these in beta for a while now (e.g., see Nick's [excellent blog post on POS extensions](https://nebulab.com/blog/building-shopify-pos-extensions)), so we’re pretty excited about this!

On the compliance front, we would have loved to see a hint at more robust compliance primitives for international merchants and regulated industries (e.g., alcohol). However, this doesn't seem to be an area that Shopify is interested in exploring at the moment, which means these merchants will still need to rely on custom-built or third-party solutions.

## Order Management: Better Control Over Complex Fulfillment

The enhancements to global commerce capabilities are matched by improvements to order management, particularly for complex fulfillment scenarios.

Significant improvements include:

* The ability to [use custom metafields to inform order routing rules](https://www.shopify.com/editions/winter2025#metafields-for-order-routing), allowing merchants to create more sophisticated fulfillment logic based on their specific business needs.
* Several improvements to Shopify Flow, the platform's built-in automation platform. Flow now [supports all Admin API actions](https://www.shopify.com/editions/winter2025#automate-more-tasks-in-flow), [can be triggered by metaobjects](https://www.shopify.com/editions/winter2025#metaobject-triggers-in-flow), and [can automate returns](https://www.shopify.com/editions/winter2025#return-automation-in-flow).
* Product catalogs [can be synced via custom IDs](https://www.shopify.com/editions/winter2025#sync-catalogs-with-custom-ids), which makes it easier for brands to integrate with in-house or third-party ERPs/PIMs. Shopify has also introduced a new [Upsert API](https://changelog.shopify.com/posts/better-data-syncing-with-custom-ids-and-upserts) to reduce the number of API calls needed for data sync.

Granted—these are all quality-of-life improvements, especially since most of this logic was already achievable via other approaches. Still, they will help a lot of brands and agencies to simplify their customizations, allowing them to redirect their efforts to initiatives that actually move the needle!

## Organizations and RBAC for More Robust Multi-Store Setups

As operations scale and become more complex, team management becomes increasingly critical. Shopify has responded with several improvements to their billing, authentication and authorization systems.

Key changes in this area include:

* The ability to [group all your stores into a single organization](https://www.shopify.com/editions/winter2025#organizations-for-all-plans) with consolidated billing and user management, a feature previously reserved for Plus merchants.
* A new [role-based access control system](https://www.shopify.com/editions/winter2025#staff-access-by-role) that lets you define granular permissions and assign multiple roles to staff members. This was announced in the Summer '24 Edition and is now entering general availability.
* Improved support for [custom authentication flows in the admin](https://www.shopify.com/editions/winter2025#standardized-reauthentication), allowing organizations to roll their own authentication provider rather than leveraging Shopify.

These organizational improvements reflect Shopify's growing focus on enterprise-level merchants who manage multiple stores and complex team structures. By democratizing features previously limited to Plus merchants and providing more granular control over permissions, Shopify is building a foundation that can better support sophisticated organizational hierarchies and security requirements. This is particularly valuable for brands operating across multiple markets or running several distinct storefronts.

## Developer Tools to Support More Complex Implementations

When it comes to developer tooling, Shopify has been hard at work to make custom storefronts and custom apps more powerful and more customizable.

Significant changes include:

* A lot of limits being raised: function executions now [support carts with up to 200 line items](https://www.shopify.com/editions/winter2025#dynamic-scaling-for-execution-limits) (useful for B2B) and [payloads of up to 128 KB](https://www.shopify.com/editions/winter2025#increased-function-input-limit). Plus, brands can now have [up to 25 app-based automatic discounts](https://www.shopify.com/editions/winter2025#functions-work-with-25-automatic-discounts).
* A number of improvements to Hydrogen, including [support for gift cards](https://www.shopify.com/editions/winter2025#hydrogen-supports-gift-cards), a [Sitemaps API](https://www.shopify.com/editions/winter2025#sitemaps-api-for-hydrogen), and a [richer GraphQL API](https://www.shopify.com/editions/winter2025#more-content-in-graphql-apis) with support for menus, pages, articles, and blogs.
* [Self-serve return endpoints](https://www.shopify.com/editions/winter2025#self-serve-return-api) as part of the Customer Accounts API, allowing brands and apps to easily build self-serve return experiences.

These developer-focused enhancements demonstrate Shopify's commitment to supporting more sophisticated implementations while reducing technical limitations that previously constrained larger operations. The increased limits and expanded APIs give developers more flexibility to build complex, custom solutions that enterprise merchants often require, making the platform increasingly viable for technically demanding enterprise implementations.

## B Is For Boring, B Is For Better

For enterprise and upper mid-market merchants, all of these improvements mean fewer workarounds, better operational efficiency, and a more reliable platform for complex implementations. This release shows that Shopify understands the needs of larger merchants and is willing to do the “boring” work necessary to support them effectively across all aspects of the platform.

As always, we recommend reviewing the full [Editions changelog](https://www.shopify.com/editions/winter2025) to understand all the changes that might impact your business.

If you need help implementing any of these new features or would like to discuss how they could benefit your operation, don’t hesitate to [reach out](https://nebulab.com/contact-us) to our team for a consultation!

Shopify Winter ’25 Edition: Not So Boring After All

A couple of weeks ago, Shopify released the [Summer ’24 Edition](https://www.shopify.com/editions/summer2024). Since its humble beginnings in the [summer of ’22](https://www.shopify.com/editions/summer2022#audiences), Editions has evolved into a major biyearly marketing initiative the Shopify team uses to update their customers and the larger commerce industry about the latest product announcements, upcoming functionality, and the general direction the platform is taking.

The splashy landing pages are then coronated by several official events, earned media (including, yes, the very article you’re reading), and fringe industry gatherings aimed at creating more hype around the platform and, by extension, the hundreds of industry players that live in its shadow and participate in its ecosystem.

And since everyone and their dog has an opinion on Editions, we thought we’d be remiss not to share our take on the most exciting announcements.

In the following paragraphs, you’ll find a recap of our favorite announcements from the Shopify Summer ’24 Edition, along with our opinions on what they mean for the future of the ecosystem.

Let’s get into it!

## You Get a Market, You Get a Market, Everybody Gets a Market

Historically, internationalization on Shopify has been challenging. For a long time, brands that wanted to start selling in other countries were forced to set up expansion stores that were, effectively, completely independent of the main store. This forced brands to sync their product catalog, settings, inventory, apps, etc., across all their stores–a Sisyphean task that often required installing clunky apps.

Then, in late 2021, [Shopify released Shopify Markets](https://www.shopify.com/news/global-by-default-shopify-markets-becomes-new-global-commerce-hub-for-merchants), a game-changing feature for brands looking to sell internationally. Markets allowed brands to sell to multiple countries from a single Shopify store while still controlling product catalogs, pricing, shipping, and other configurations on a per-country basis. Markets simplified international selling on Shopify dramatically and was acclaimed positively by both agencies and brands.

One year later, [Shopify released B2B](https://www.shopify.com/enterprise/blog/b2b-on-shopify), making it easier for brands to sell wholesale. Shopify B2B allowed merchants to manage company profiles, configure B2B-specific payment methods and terms, and set up dedicated price lists. It came at a time when more brands were looking at B2B to drive profitable growth and allowed brands to manage their wholesale operations from the same platform they knew and loved for DTC.

Until now, Markets and B2B have been entirely independent, each functioning according to different rules and concepts and configured in their respective UIs. Add to this Shopify POS, [which was launched in 2013](https://www.shopify.com/news/shopify-launches-revolutionary-point-of-sale-system) and also operated as a completely separate sales channel. Understandably, this created friction for merchants, who needed to navigate a complex maze of settings and rules to determine how their brand shows up in different channels.

![](https://cdn.sanity.io/images/kqgmf0g2/production/d624cc7cae90e895dd78cf1ee360266218b672ea-1280x720.jpg?fit=clip)

In the Summer ’24 Edition, Shopify announced that [Markets will become a unified home](https://www.shopify.com/editions/summer2024#markets) to manage all of your brand’s expansion efforts, whether you’re talking about new countries, B2B, or POS. For each channel, you can now configure the product catalog, availability, pricing, and much more from a single UI, and you can even combine different types of markets (e.g., all retail stores in the UK).

This not only gives brands an unprecedented amount of flexibility, but it also dramatically reduces the operational effort of maintaining multiple sales channels.

Finally, Shopify also announced that [each market will be able to use a separate business entity](https://www.shopify.com/editions/summer2024#multiple-business-entities) for payments. This long overdue change often prevented international brands from adopting Markets, forcing them to use expansion stores with all their quirks and limitations.

Our team was pretty excited about this change: It brings much-needed consistency to several areas of the platform and unlocks a range of use cases that were not possible before, such as having completely different themes for different markets or having complete control over the product catalog available to retail stores. It all _feels_ right, as evidenced by the ecosystem’s overwhelmingly positive response.

The new Markets experience is not available to the public yet, but you can [sign up](https://www.shopify.com/editions/summer2024#markets-top-10) to get notified when it will be released.


## New Shopify POS Functionality Gives Your Retail Stores Superpowers

Besides Markets, Shopify has put a lot of effort into making sure that all the different sales channels they offer to merchants are fully integrated. In the process, they’ve resolved some annoying gotchas and inconsistencies that had bothered merchants for years and unlocked new, exciting use cases.

POS got a lot of love in this regard. First of all, the POS hardware is now available in nine new countries–Belgium, Denmark, Germany, Ireland, Italy (yay!), the Netherlands, New Zealand, Spain, and the UK. In the last few years, we’ve seen pretty strong demand for Shopify’s POS devices in Europe, so it’s great to finally be able to offer them to merchants–Shopify’s hardware is excellent, and we can’t wait to experiment with it a bit more.

Secondly, Shopify is also enabling truly unified shopping experiences with two new features that bridge the gap between online and offline:

* [Ship to store](https://www.shopify.com/editions/summer2024#ship-to-store), which boosts Shopify’s existing BOPIS (Buy Online, Pickup In Store) functionality by allowing customers to choose their favorite pickup location regardless of inventory availability. When the product is unavailable, Shopify will seamlessly orchestrate delivery to the customer’s chosen pickup point.
* [Ship from store](https://www.shopify.com/editions/summer2024#ship-from-store), which allows merchants to use their stores as last-mile fulfillment networks. Online orders will appear on the retail store’s POS interface, from which store operators can fulfill the orders or, if unable, delegate fulfillment to another location or back to a standard fulfillment center.

![](https://cdn.sanity.io/images/kqgmf0g2/production/4b3bebec01781cec89054946a6bb6a758e528894-1280x720.jpg?fit=clip)

Finally, POS became more intelligent and more integrated with the rest of the Shopify ecosystem. This includes functionality such as:

* [One-tap digital receipts](https://www.shopify.com/editions/summer2024#digital-receipts-with-opt-ins), which can be delivered by email, text, or, if the customer has a Shop Pay account, to the Shop app.
* The ability to [collect personal information](https://www.shopify.com/editions/summer2024#require-info-at-checkout) such as name and email, marketing opt-ins, and sales staff attribution at checkout.
* Automatic integration with your store’s [return rules](https://www.shopify.com/editions/summer2024#return-rules), which reduces the likelihood of out-of-policy returns.

Combined, these features allow brands to make the most of their physical stores, reducing fulfillment costs, improving the customer experience, and helping brands collect more zero-party data. In an era when all merchants are trying to do more with less, this is the sort of innovation that we like to see from Shopify.

## Checkout Is Getting a Flexibility Boost 

Shopify’s checkout has long been a significant component of the platform’s value proposition and, at the same time, one of its biggest weaknesses. While it’s great for merchants to be able to delegate compliance concerns or checkout CRO to Shopify, the lack of customizability in the checkout flow has prevented specific categories of brands from implementing their ideal customer experience or, in some instances, from adopting Shopify altogether.

Some of this rigidity is by design: Shopify doesn’t want brands to shoot themselves in their metaphorical foot by making changes that could negatively impact their conversion rates. Finding the right balance between flexibility and compliance with industry regulations is also challenging, especially with the new limitations imposed by [PCI DSS v4](https://www.shopify.com/partners/blog/checkout-compliance).

That said, Shopify has been doing some great work on this front over the last few years by adopting a two-pronged approach: They’ve been opening up the checkout to more types of customizations and more elaborate use cases, but they’ve also been forcing merchants to use a set of standardized APIs (dubbed [Checkout Extensibility](https://www.shopify.com/enterprise/blog/checkout-extensibility-winter-editions)) to alter their checkout flow.

![](https://cdn.sanity.io/images/kqgmf0g2/production/bf8f13000bd1a4fc566adcfea2f55adb32bde12a-1280x720.jpg?fit=clip)

In the latest Edition, Shopify has continued on this path by releasing a slew of new features and customization APIs for their checkout:

* [Checkout Blocks](https://www.checkoutblocks.com/), a third-party app that allowed merchants to apply complex customizations to their checkout in a no-code UI, has been acquired by Shopify and is now free for all Shopify Plus merchants. It’s a fantastic product, and we couldn’t be happier for [Gil](https://www.linkedin.com/in/gilgreenberg/) and his team!
* Checkout will soon support [split shipping](https://www.shopify.com/editions/summer2024#split-shipping), allowing customers to see when an order will be split into multiple shipments and pick a different shipping method for each shipment. On a similar note, it’s now possible to [capture partial payments](https://www.shopify.com/editions/summer2024#payment-per-fulfillment) when part of an order is fulfilled.
* In a move that will undoubtedly be appreciated by brands outside the US, Shopify is now offering the ability to implement third-party integrations for [pickup points](https://www.shopify.com/editions/summer2024#3p-pickup-points-api) (not available yet) and [address autocompletion](https://shopify.dev/docs/api/checkout-ui-extensions/unstable/targets/utility/purchase-address-autocomplete-suggest), as well as to collect region-specific [address fields](https://www.shopify.com/editions/summer2024#region-specific-addresses) and different forms of [tax ID](https://www.shopify.com/editions/summer2024#tax-id-fields) for individual and business customers.
* Developers can now use the [Checkout Branding API](https://shopify.dev/docs/apps/build/checkout/styling) (available to Shopify Plus merchants only) to configure the checkout flow’s overall styling and UI elements. Additionally, they can [pre-fill the address at checkout](https://www.shopify.com/editions/summer2024#prefilled-addresses), which is handy for gift and wedding registries and other non-traditional shopping experiences.

These changes, most of which are targeted at international brands or brands with complex use cases such as marketplaces, give merchants some much-needed flexibility while still allowing Shopify to guarantee compliance and retain control over the end-user experience. 

In fact, we were working with a couple of brands waiting for some of this functionality to switch to Shopify, and we can’t wait to try it in the wild.

## Analytics, Controls, and Automation for Operators That Mean Business

Last but not least, Shopify announced a range of new features aimed at larger, more sophisticated brands that need greater visibility into and control over their businesses.

The spotlight goes to the [new Shopify Analytics](https://www.shopify.com/editions/summer2024#rebuilt-analytics), which allows merchants to build advanced custom reports and dashboards and, soon, query their data directly using ShopifyQL. Combined, these two features unlock much greater flexibility when it comes to business analytics, reducing the need for merchants to roll out and maintain dedicated business intelligence infrastructure.

![](https://cdn.sanity.io/images/kqgmf0g2/production/b489a739028c98fd8168cafd505dd0874b2b0c52-1280x720.jpg?fit=clip)

Organization settings and staff access also received some love. While the details are not completely fleshed out yet, it looks like companies will soon be able to [manage multiple stores from a unified interface and](https://www.shopify.com/editions/summer2024#organization-settings) assign staff access through a [Role-Based Access Control (RBAC) system.](https://www.shopify.com/editions/summer2024#role-based-access-control)

Finally, Shopify is releasing several improvements for Shopify Flow, their built-in task automation platform. Flow is becoming more powerful (thanks to features such as the ability to [send direct requests to the Admin API](https://www.shopify.com/editions/summer2024#send-admin-api-in-flow)), easier to use (see the [improved UX for working with metafields](https://www.shopify.com/editions/summer2024#custom-data-for-flow)), and more convenient to debug when something goes wrong (with a [better search experience](https://www.shopify.com/editions/summer2024#search-runs-for-flow) and [manual reruns](https://www.shopify.com/editions/summer2024#manual-reruns-in-flow)).

While Flow still leaves a lot to be desired (how much longer until we can use the result of an API call inside Flow?!), it’s a robust product for automatic basic tasks in a low-code environment. In fact, we’ve been able to use it in several instances where we would have previously reached for a custom app or an external automation platform, such as Zapier.

## Hydrogen Gets The First-Class Treatment: Visual Editor and B2B Storefronts

On the headless front, much work went into creating consistency between Hydrogen’s off-the-shelf capabilities and what brands can do with Online Store.

The most prominent announcement here was the new [Hydrogen Visual Editor](https://www.shopify.com/editions/summer2024#hydrogen-visual-editor), based on an open-source solution called Utopia. The editor, which is yet to be released, will allow marketers to manage the content of their storefronts through a visual page builder.

Furthermore, the new visual editor _actually updates the underlying code_ of your storefront rather than loading content through a client-side network call. This comes with several benefits, including much faster page load times and all the goodies of Git-based version control.

In the past, we’ve had to roll out similar features manually through solutions such as Sanity and Builder.io, so it’s great to have this out of the box and officially supported by Shopify. That said, we were surprised that Shopify didn’t just acquire an established player in the space, such as [Pack](https://packdigital.com/) or [Instant](https://instant.so/), and integrated their solution natively.

We’re also still waiting for the day when Shopify will decide to unify its content management solutions, using the same technology across Online Store and Hydrogen. Perhaps this is a small step in that direction.

![](https://cdn.sanity.io/images/kqgmf0g2/production/257a779594efae973c9a1d3fe3c5d84b98eb04e0-1280x720.jpg?fit=clip)

In addition to the Visual Editor, it is now possible to launch [headless B2B storefronts](https://shopify.dev/docs/storefronts/headless/bring-your-own-stack/b2b)–a feature that was previously only available for Online Store. There’s even a [Hydrogen B2B template](https://github.com/Shopify/hydrogen/tree/main/examples/b2b) that you can leverage to speed up time-to-market if you wish.

These are the major announcements, but Shopify also announced [many additional improvements to Hydrogen](https://hydrogen.shopify.dev/update/summer-editions-24-announcing-the-hydrogen-visual-editor-and-a-ton-of-dx-improvements), such as an optimistic cart API for instantaneous cart updates, official support for Vite, native integration with Shopify Analytics and the Customer Privacy API, better environment variable management, and improved SEO tooling.

One of the main problems with headless Shopify architectures has been the feature and capability gap between Hydrogen and Online Store. There are still inconsistencies to figure out, especially when it comes to the app ecosystem. Still, with some of these announcements, it feels like we’re getting closer, which is excellent news for all merchants that need a more sophisticated storefront than what Liquid themes allow.

## There’s Much More…

In this article, we have deliberately omitted a lot of stuff, cherry-picking the announcements and capabilities that were most relevant to the work we typically do with our clients. We didn’t talk about the [improvements to Shopify Magic](https://www.shopify.com/editions/summer2024#ai-for-commerce) or all the work Shopify is doing around [third-party sales channels and Shop](https://www.shopify.com/editions/summer2024#connect-with-customers), their own marketplace. If you run a Shopify brand, we encourage you to check out [the official Editions site](https://www.shopify.com/editions/summer2024#connect-with-customers) to ensure you’re not missing anything!

That said, it’s clear that Shopify plans to continue pushing in all directions. For smaller brands, they are rolling out features that allow them to do more with less, leveraging the strength of Shopify’s ecosystem and economies of scale.

For larger brands, they’re making the platform more flexible to support more complex use cases. At the same time, though, they’re also creating consistency and feature parity across different flavors and sales channels to minimize the amount of gotchas and “insider knowledge” required to navigate the Shopify universe.

Given the size of that ecosystem, it’s an uphill battle, but if anyone has the market traction and R&D budget to pull this off, it’s Shopify–and we’re excited to be part of the ride.

Shopify Summer ’24 Edition: Are Things Getting Serious?

eCommerce operators often tell us that picking the right tech stack for your eCommerce brand feels like walking on a tightrope. There are so many tools and technologies to choose from, and making the wrong decision can severely impair your online store’s ability to scale with your business.

In this guide, we’ll look at what a tech stack is, why building it is a critical phase in your brand’s life, and how you can create a tech stack that will support your goals and your brand’s evolving requirements.

## What is a tech stack?

In layperson’s terms, a technology stack (“tech stack” for short) is a collection of programming languages, software libraries, frameworks, databases, and online services integrated to deliver a particular user experience.

While some of these technologies are very generic and apply to all kinds of scenarios, others are specific to the eCommerce industry. Here are the basic building blocks of most modern tech stacks:

* **Programming languages:** Developers use specific programming languages (e.g., Ruby, JavaScript, PHP, Java, Python) to code the server-side and frontend logic behind your application. Different languages have different properties and capabilities when it comes to popularity, scalability, and developer experience.

* **Libraries and frameworks:** These are software packages that make it easier for software developers to implement standard functionality. For instance, most backend programming languages provide Web frameworks that speed up the implementation of Web applications, such as Django for Python or Ruby on Rails for Ruby.

* **Infrastructure:** Infrastructure consists of the Web server, database, and other components that run your application’s backend and frontend code and host its data. Depending on your use case and requirements, many different types of infrastructure providers and possible configurations exist: e.g., you may use a relational database like MySQL, or a NoSQL database like MongoDB.

* **SaaS providers:** This is a catch-all term to indicate all the third-party software you pay a recurring fee to access. It can be a small piece of your stack, such as an analytics service or automation platform, or a major component, such as the eCommerce platform your brand runs on.

As you may imagine, picking the right mix of frontend and backend technologies, libraries, infrastructure, and SaaS providers requires a lot of experience: First of all, not all components integrate well with each other; secondly, each set of technologies has its pros and cons, which are very context-dependent.

While recommended practices exist, any agency or Web development team pushing the same software stack onto all of their customers is doing them a huge disservice. **Using the wrong tech stack can slow down your development process, prevent you from efficiently capitalizing on business opportunities, and hold back your startup from scaling.**

In the following paragraphs, we’ll explore the most critical parts of an eCommerce brand’s tech stack and how to make informed decisions when discussing them with your agency or in-house developers.

## What are the components of an eCommerce tech stack?

![Image of an hand that holds a rainbow-coloured MasterCard with two fingers](https://cdn.sanity.io/images/kqgmf0g2/production/4c046c881c959d397caaedf2278e3a95741ec830-1920x1080.jpg?fit=clip)

The average eCommerce brand may integrate many tools and technologies to deliver and optimize their customer experience. Let’s look at some of the most common eCommerce technology you might make as an operator or developer.

### eCommerce platform

Your eCommerce platform (sometimes called “shopping cart”) is the core of your business. Picking the right eCommerce platform is a critical decision when launching or re-launching your online store and one that you should evaluate from many angles.

There are many players in this space, and they come in different shapes and forms: established solutions such as [Shopify](https://shopify.com/) and [BigCommerce](https://bigcommerce.com/) promise reliability and large ecosystems. In contrast, newer solutions such as [Swell](https://swell.is/) and [Commerce Layer](https://commercelayer.io/) offer flexibility and a more modern approach. Then you have disruptors such as [Solidus](https://solidus.io/) (which is open-source) and [Chord Commerce](https://chord.co/) (which is data-driven), which push for a completely different take on building and operating your brand.

You can learn a bit more about the state of the eCommerce platforms market in our article on [headless vs. monolithic eCommerce](/blog/headless-commerce).

### Payment processing

Payment processing is a big part of running an eCommerce business. All eCommerce brands integrate with one or more vendors in the space, called PSPs (Payment Service Providers).

Note that “payment method” and “payment service provider” (or “payment gateway”) are sometimes used interchangeably. Still, they have two different meanings: while a payment method represents a medium the customer uses to pay for goods and services (e.g., credit card, Apple Pay, Google Pay), a payment service provider is a company that builds software to enable specific payment methods. For example, credit cards are one of the most common payment methods in eCommerce. To accept credit card payments, you must partner with a PSP that provides that service, such as [Stripe](https://stripe.com/).

You can either decide which payment methods you want to support and then pick the right combination of PSPs, or pick a PSP you want to use and then choose which payment methods you wish to enable among the ones they support.

There’s no right or wrong answer: whether to go one way or the other depends on your market (e.g., US vs. EMEA), business model (e.g., B2C/B2B), customer demographics (e.g., Gen X vs. Gen Z, household income) and industry (e.g., THC products are highly regulated and only supported by specific PSPs).

### Logistics

The supply chain experience can make or break a brand’s shopping experience. Especially for DTC, the bar is high, with consumers constantly comparing you with their latest experience and not settling for delivery delays or order mix-ups.

“Logistics,” in the context of an eCommerce operation, encompasses at least three different components, which may or may not be provided by the same vendor:

* **Inventory management:** an inventory management system allows you to track the inventory in your warehouse(s). Modern WMSs integrate with your eCommerce platform for real-time stock counts.

* **Shipping management:** a shipping management system allows you to generate shipping labels and track your packages’ journey from the warehouse to the customer.

* **Returns management:** a returns management system allows you to define your return policies, enables customers to handle returns autonomously, and tracks returns on their way to the warehouse.

You can either build/buy these tools and handle your logistics in-house or partner with a 3PL (third-party fulfillment) vendor to store your inventory and handle all logistics- and fulfillment-related responsibilities on your behalf. Which way to go depends on your company stage, product category, market, and many other factors.

### Content management

Depending on your needs, choice of eCommerce platform, and frontend technologies, you may or may not need to pick a content management system (CMS). A CMS allows you to manage the marketing content that appears on your eCommerce website.

Headless CMSs are all the rage nowadays: they allow developers to specify which content types are supported and how they should be presented on screen while still allowing marketers to publish whatever content they want, whenever and wherever they want. This gives your team much power while maintaining a consistent presentation of your content across your storefront, mobile app, and other sales channels.

With that said, headless CMSs are also restrictive: if a particular content module is not supported, your team won’t be able to publish it until a developer implements it. Whether to go with a headless (e.g., [Contentful](https://www.contentful.com/)) or monolithic CMS (e.g., [Webflow](https://webflow.com/)) depends on your scale, technical capabilities, and editorial needs.

For more details, read our article on [eCommerce content management](/blog/ecommerce-content-management).

### Marketing

Reaching your customers at the right touchpoints, and offering relevant, personalized information and offers, is an unbeatable advantage of online shopping. Brands can leverage first-party data to create “aha!” moments and magical experiences, but only if they are supported by the right tools.

You will find many marketing tools serving different channels and purposes: some tools are specifically built for email/SMS marketing, while others will be more targeted at social media marketing. Some tools are specifically designed for eCommerce companies; some are generic but do a good enough job of accommodating the needs of an online brand.

Our suggestion? Start simple. Going too aggressively after too many channels might cause you to disperse your efforts. Instead, be very intentional about which channels you’re pursuing, your segmentation strategy, and how to ensure that all the information you have about your customers is being put to full use. Once you have an established strategy, you can start to iterate and experiment.

### Customer support

Expectations around customer support (“CS”) have never been so high, and the bar is set even higher for digitally-native brands, which have pioneered a new era of customer support. Customers expect you to be responsive, solve their problems, and go above and beyond to provide a memorable experience.

Different CS software solutions support different channels (e.g., email, SMS, phone, social media), and covering as much ground as possible is critical in implementing a successful customer support strategy. If you have an Instagram account, customers expect their complaints to be answered there, not just by email.

Also, when those customers do reach out, you want to have the correct data at your disposal, so make sure your customer support platform integrates well with the rest of your stack: for example, when a customer reaches out, can you quickly identify them and see what they’ve purchased, and maybe initiate a return from within the CS tool itself? The more manual work you eliminate from the process, the easier it will be for your team to offer stellar support.

### Business intelligence

Data is an eCommerce store’s superpower. When a customer buys from you, you instantly get access to a ton of precious information about them and their behavior. You can either aggregate these bits of information to generate valuable insights for your business strategy, drill down to the customer level, or use the data to offer hyper-personalized experiences (ideally, you do both).

Building the right business intelligence (BI) infrastructure is a topic of its own, and entire books have been written about it. Many ready-made solutions allow eCommerce brands to track user behavior and generate fundamental reports and insights about their business. Highly sophisticated solutions enable brands to model their tracking, ETL, and data mining processes.

When it comes to business intelligence, we strongly encourage brands to be intentional about what they’re doing: it’s easy to implement a million different tracking pixels, tools, and reports and still be unable to generate any actionable insights. Start from the questions you want to answer, understand what data will help you answer them, and pick the right tool(s) for the job.

## 8 tips for building your tech stack

![Picture of a green crossroads into the wood](https://cdn.sanity.io/images/kqgmf0g2/production/ef51951e452f8432f6a43df46b9a9c9c598058dd-1920x1285.jpg?fit=clip)

The good news for eCommerce companies is that there are an incredible amount of solutions for launching and operating a brand. The bad news is that, with so many established players and new ones popping up daily, making a choice can feel overwhelming, and the consequences can be disastrous.

Here are eight tips that you should use to build your brand’s tech stack or when evaluating a change in your existing stack:

* **Ease of integration:** some solutions will be easier to integrate, thanks to public APIs and built-in connectors. When building your tech stack, pay attention to how the different parts of your stack will communicate. An integrated tech stack means less manual work and a better customer experience.

* **Build vs. buy:** buying an existing solution is not always the right choice. If you don’t find any vendors that fit your business needs, consider building an in-house solution that will scale with your brand over time. However, be mindful that this comes with caveats (e.g., higher upfront costs)!

* **Hot vs. boring:** should you jump on the latest hot trend or pick a boring solution that has stood the test of time? Unfortunately, there’s no correct answer: sometimes, some experimentation can give you a competitive advantage. But if you overdo it, you can expose your business to unnecessary risk.

* **Pricing:** it may seem obvious that you want to evaluate pricing when building your tech stack. However, we encourage you to look beyond the Pricing page, considering the expected lifespan of the solution, the total cost of ownership, and even the opportunity cost.

* **Decision reversibility:** some tech stack decisions are more challenging than others to reverse. Switching your customer support tool is rarely too complicated, but migrating to a new eCommerce platform is a big deal. Keep this in mind when making a choice.

* **Compliance:** in specific markets and business verticals, you will need to worry about compliance and regulatory issues. Sales tax, the CCPA (in the US), and the GDPR (in the EU) are the usual suspects, but the needs will evolve with your business, so you will need to stay on top of things.

* **Scalability:** while everyone loves to talk about scalability in the performance sense (e.g., how well a solution handles high traffic volumes), that is rarely a problem in most scenarios. Instead, understand how well the solution will support your evolving requirements and how likely you will need to move away from it as your brand grows.

* **Customer support:** we’ve discussed the importance of offering excellent customer support as a brand–you should hold your vendors to the same standard. Look at SLAs, support channels, and even G2 reviews. Ideally, talk to someone who’s already a customer and get their feedback!

## Do you need help building your tech stack?

Hopefully, we’ve convinced you that building your eCommerce brand’s tech stack is no easy feat. It’s a complicated, multi-layered process critical for ensuring your brand’s long-term success.

If you’re launching your brand or need to overhaul your existing brand’s tech stack, we can help. Our eCommerce engineers have worked with tens of brands over the years and can help you make the right decisions, enabling you to move quickly and laying the foundations for aggressive growth.

[Reach out](/contact-us) to tell us more about your project!

How to Build Your eCommerce Tech Stack

For a long time, Shopify has been considered as the eCommerce platform for SMBs: easy to set up and maintain, with the largest ecosystem of integrations and service providers in the industry, the original promise of Shopify was to [arm the rebels](https://shopifyrebellion.gg/), giving every entrepreneur everything they need to launch an online store. This value proposition attracted millions of small businesses to the platform.

Historically, the downside of Shopify’s ease of use has been its lack of flexibility: Shopify has always been a featured-packed but ultimately closed platform, unable to offer the technical sophistication of competitors catering to the enterprise eCommerce space, such as [Salesforce Commerce Cloud](https://www.salesforce.com/products/commerce/) and [commercetools](https://commercetools.com/). Enterprise requirements demand a much more open and extensible architecture, which was at odds with Shopify’s promise of power and simplicity.

But in the last couple of years, Shopify has used its traction to push hard upmarket, with products such as [Hydrogen](https://nebulab.com/blog/shopify-hydrogen) and [Commerce Components](https://www.shopify.com/commerce-components) that are meant to appease the needs of the enterprise segment. The result is two-fold:

* Shopify has been eating into the market of its enterprise competitors. For enterprise brands, Shopify is a compelling product with incredible traction.
* SMBs have been taking an interest in more advanced architectures, such as headless and composable commerce, that Shopify did not offer before.

The fact that Shopify offers three different architectures, their original Online Store product plus Hydrogen and Commerce Components, and two commercial offerings, Shopify and Shopify Plus, often leaves operators confused and prone to analysis paralysis. In the worst-case scenario, we see brands make the wrong choice, leading to a more complex and fragile architecture than they were prepared for.

In this article, we want to provide a map for anyone looking to navigate Shopify’s different offerings and flavors so that you can make the right decision for your brand and maximize the return on your investment.

Let’s dive in!

## Online Store: Small but Mighty

Let’s start with the most basic and popular option: Online Store.

In technical terms, Online Store is Shopify’s monolithic commerce product, meaning that your e-commerce platform and storefront are bundled in the same package. When you go with Online Store, you can customize your store in two ways: by editing your theme (either through Liquid templates or the Theme Editor) or by installing apps from Shopify’s App Store.

In other words, when you use Online Store, Shopify controls and delivers your entire commerce experience end-to-end. This creates a streamlined experience for you and your Shopify developers: the Theme Editor will allow you to make most content changes yourself. Certain Shopify themes will even auto-update to the latest version–as long as you haven’t modified them too heavily–so you won’t need to use developer hours for theme updates.

![](https://cdn.sanity.io/images/kqgmf0g2/production/05cb8d62586c75912162aeed16bccd3b447caef5-1600x1052.jpg?fit=clip)

The most significant advantage of using Online Store, however, is the size of the ecosystem you will be able to access: pretty much every Shopify App has been built with Online Store in mind, which makes it incredibly simple to add new functionality to your store with a click of a button. The same goes for agencies and system integrators: most developers in the Shopify ecosystem are used to working with Online Store architectures, so it will be much easier to find someone to help you.

What’s the catch, then?

Well, as we mentioned in the introduction, larger brands have scoffed at this flavor of Shopify because it lacks flexibility and technical sophistication. As your store grows, you might start bumping into certain limitations that make it hard to keep a high quality bar: apps that don’t play nice with each other, performance issues that cannot be easily mitigated, and new features that cannot be implemented without unreliable workarounds.

To be fair, some of these issues are not caused by Online Store per se, but rather by an inexperienced development or marketing team that abuses the plug-and-play nature of this architecture and ends up shooting themselves in the feet.

However, it’s undeniable that Online Store offers less control to Shopify merchants than the alternatives, so let’s look at what else Shopify has to offer!

## Hydrogen: Let’s Lose Our Heads

[Hydrogen](https://nebulab.com/blog/shopify-hydrogen) is Shopify’s headless ecommerce product, and it was their first answer to more complex customization needs. Released in late 2021, the Hydrogen framework gives brands complete control over their shopping experience, allowing them to build custom frontends with literally no limitations.

In practice, the way Hydrogen works is that, rather than building a theme, which you then upload to Shopify, you create your Hydrogen storefront as a completely standalone JavaScript/React application that leverages a set of pre-built components provided by Shopify. This custom storefront will still use Shopify’s Storefront API to power most of its functionality, but because you control the entire codebase, you can easily implement custom functionality that Shopify’s backend doesn’t support and create richer customer experiences.

You can deploy Hydrogen apps on [Shopify Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen), Shopify’s free hosting solution, or any other hosting platform that supports JavaScript, such as [Vercel](https://vercel.com/).

As we’ve already mentioned, the main upside of Shopify Hydrogen is control: with a headless store, the sky is quite literally the limit, and whether you can accomplish something mostly depends on how many resources you want to invest into the project. This flexibility allows brands to really push the boundaries of digital commerce and offer lightning-fast, highly engaging user experiences. By giving you more granular control, headless storefronts also make it easier to fine-tune your site’s speed and customize your integrations.

On the other hand, this level of control is not for everyone: if you want to go with Hydrogen, you need to ensure your development team has experience with headless solutions. Otherwise, you’re bound to create more problems than you’re solving. You can also expect the development and maintenance of your Shopify store to become a bit more complicated as you lose access to some of Online Store’s let-me-do-that-for-you functionality.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a6338ec311c8c4db7308b78bed520d05dd67fbc0-1600x1052.jpg?fit=clip)

The other significant downside of going with Hydrogen is losing access to a big part of Shopify’s ecosystem: as we’ve mentioned earlier, most Shopify apps, and even many of Shopify’s internal features, have been built for Online Store shops. Hydrogen stores can forget about the Theme Editor and one-click app installations; instead, you will need to pick content management and other technology providers that offer an API, and then [implement and maintain those integrations yourself.](https://hydrogen.shopify.dev/integrations)

But what if not even headless commerce cuts it, perhaps because you have an existing eCommerce infrastructure that you want to migrate to Shopify more gradually, or because eCommerce is just one part of a much larger retail setup? 

Those are the kinds of problems that Commerce Components was built to solve.

## Commerce Components: The Composable Way

[Commerce Components](https://www.shopify.com/commerce-components) is Shopify’s answer to the rise in popularity of composable commerce, especially among enterprise merchants.

On the surface, composable architectures are not dissimilar from headless architectures: rather than having everything in one place, your Shopify storefront is implemented and hosted separately from your eCommerce stack and interacts with it through APIs. _Unlike_ in a headless architecture, however, you’re not just integrating with one service provider, but stitching together a plethora of them by picking the best-in-class provider in each category.

Let’s look at a practical example: the first component Shopify is making available as a standalone offering is Shop Pay, their accelerated checkout. That means you can use Shop Pay as your checkout even if you don’t use Shopify for Product Information Management (PIM) or as your Order Management System (OMS).

![](https://cdn.sanity.io/images/kqgmf0g2/production/0ae4e563810428092df43dce23463b6af5070fc2-1600x1052.jpg?fit=clip)

For large merchants, this is a very compelling proposal: it’s much easier to integrate smaller pieces of Shopify as needed rather than uprooting their entire tech stack. For Shopify, it’s a powerful way to get a foot in the door and eventually win more of a merchant’s business–as they’ve reiterated repeatedly in their recent earnings calls.

It’s crucial to note Shopify is very new to the composable space, and it will most likely take a while before Commerce Components becomes a first-class citizen in their ecosystem. Right now, it’s being used by some very large retailers, such as [Glossier](https://www.glossier.com/), but Commerce Components is a recent offering, and there’s still not much information about it. All Commerce Components deals need to go through Shopify’s sales team and are being discussed on a case-by-case basis–you can’t just sign up on your own and start building.

As cool as it may sound, the complexity of a composable architecture is not for the faint of heart. Think headless development, but times ten, because now you need to stitch together even more pieces. This architecture typically requires a dedicated engineering team, and it’s most often adopted by brands that treat technology as a first-class citizen: if you don’t have a CIO, CTO, or VP of Technology, Commerce Components is _almost certainly_ not for you.

If, on the other hand, you’re an enterprise brand running on a legacy infrastructure that you’d like to modernize, Commerce Components allows you to do so progressively and without dramatically disrupting your existing workflows or technology.

## So, Which One Should You Use?

If you still have doubts at this point, here’s a quick cheatsheet to understand what Shopify version to go with depending on your ecommerce store’s maturity:

* If you’re below $100M in annual GMV, just stick with Online Store. The simplicity of having everything in one unified package and the power of Shopify’s ecosystem will more than compensate for the lack of flexibility.
* If you’re beyond $100M in annual GMV and constantly running into technical limitations with Online Store, you might want to start evaluating Hydrogen. However, make sure to pick a partner that can support you and will not be scared by digging into the more technical aspects of running your store.
* If you’re a large/enterprise ($300-400M+ in annual GMV) retailer with a complex infrastructure and an established engineering discipline and want to either migrate to Shopify or integrate specific pieces of Shopify’s offering, Commerce Components might be a good fit.

With that said, keep in mind that these recommendations are a floor, not a ceiling: we have worked with small/medium brands that were ambitious and technical-savvy enough to go with Hydrogen well below the $100M/year threshold, and we’ve worked with brands doing $300M/year through Online Store. Any choice you make should be made in the context of _your_ business needs and capabilities–that’s where picking a strong technical partner with a broad understanding of these offerings can have a considerable impact.

If you need any help making a decision, we’d love to help! Our team has extensive experience working with brands from pre-revenue to $500M/year, and can advise on the best technical architecture for your brand. [Feel free to reach out!](https://nebulab.com/contact-us)


Comparing Shopify’s Online Store, Hydrogen, and Commerce Components

Stefano Sarioli

For an eCommerce brand, replatforms are always exciting projects that hold a lot of promise: a replatform can come with increased flexibility, lower maintenance costs, and a better customer experience that can significantly impact your top-line growth.

However, replatforms are also incredibly stressful and can quickly become a nightmare when they’re not planned or executed appropriately: because they’re large and irreversible projects, it’s easy to miss something important and only realize it too late. Suddenly, what was supposed to be a growth driver for your business turns against you, leaving your board, team, and customers unhappy.

In this article, we will share some strategies we follow when guiding our clients through a replaform, from picking your new eCommerce platform all the way through implementation and launch. Hopefully, we can help make your next replatform a bit less scary!


## 1. Start With the Why

This one should be obvious, but you’d be surprised how many store owners cannot clearly articulate why they are executing a replatform.

A replatform project is a big undertaking from many perspectives:

* **It takes time**: replatforms will take up a lot of your team’s time and energy. In our experience, most re-platforms take anywhere between 2-5 months, depending on the complexity of your online store. Enterprise replatforms can take years!
* **It’s expensive:** replatforms are expensive projects, no matter whether you use your internal team or work with an agency. Trying to cram a replatform into a tight budget is a recipe for disaster, so make sure you can allocate the right resources.
* **It’s risky:** re-platforms are inherently risky. While most software projects can be approached incrementally, re-platforms require a big-bang transition, dramatically increasing the likelihood of something going wrong.
* **It impacts morale:** for some of your team members, the replatform will come with a steep learning curve, considerable disruptions to their existing workflows, and even fears about their career opportunities (“Will this new skillset make me less relevant?”).

With all that is at stake, you want a crystal-clear understanding of why you need to replatform: you owe it to your team, your customers, and yourself. Some of the most common scenarios in which it makes sense to do a replatform are:

* **To increase flexibility.** If your platform is consistently preventing you from executing your digital roadmap, then it’s time to look for more advanced vendor–that is, provided that your roadmap is the result of an [intentional, data-informed product management workflow.](https://nebulab.com/blog/ecommerce-product-management)
* **To support growth.** If your existing platform is having growth pains, then you might want to switch to a more scalable solution that will support your brand’s long-term plans.
* **To reduce maintenance costs.** Some platforms are more expensive than others to keep up and running. Sometimes, this is an acceptable cost to pay for certain benefits (such as additional features), and sometimes it’s a non-justifiable expense.
* **To access a larger ecosystem.** If you can’t find any partners or system integrators willing to work with your current setup, and this is preventing you from reaching your business objectives, then it might be time for a change.

There are also many _bad_ reasons to do a replatform, such as your team only having experience with a specific stack (they can learn a new technology), fear of missing out because everyone else is using a different solution (they are not you), or an investor pushing you hard to make the switch (it’s unlikely they fully understand your business needs).

We suggest writing a [Request for Comments](https://nebulab.com/blog/driving-organizational-change-with-rfcs) about the replatform. This will help you analyze your motivations and assumptions, evaluate potential alternatives, and ensure that a replatform is the right move for your eCommerce store.

RFCs have the added benefit of helping you build commitment and create alignment on the project internally–and believe us, it’s something you will need badly if you move forward.


## 2. Think Brand First, Not Vendor First

So, you wrote an RFC, you discussed it with your team, and you’re all aligned on your motivations. The next question is, how do you compare the capabilities offered by different vendors?

Nowadays, there are tens of eCommerce platforms to choose from. As in most crowded software categories, they all offer a base layer of foundational functionality and a certain number of differentiators that make them stand apart. Some of these differentiators will be useful for your specific needs, while others are just marketing stunts that will lure you in but ultimately prove irrelevant.

When approaching a replatform, we typically categorize business requirements in one of three buckets–Big Rocks, Pebbles, and Sand:

* **Big Rocks:** these are major pieces of functionality. They are highly specific to your brand promise and business model. For membership-based brands, for instance, the #1 Big Rock is their membership billing engine.
* **Pebbles:** these requirements are still important but not unique to your brand. An example would be your average ERP or 3PL integration. For most brands, there’s not a lot of innovation involved in these foundational eCommerce features.
* **Sand:** these are minor requirements that can be taken more or less for granted. Most cosmetic improvements, such as the image carousel on your PDP, fall into this category.

![](https://cdn.sanity.io/images/kqgmf0g2/production/ee19cec17172531bd1e236882c503471ca249262-3200x2104.jpg?fit=clip)

Once you have this mapping, you can understand how the platforms you’re evaluating will solve your requirements, prioritizing each requirement depending on how it’s been categorized. Feel free to ask the vendors you’re considering for help during this phase: after all, they know their own solutions inside out. However, you should always double-check their claims, as they are bound to be biased.

Whatever you do, make sure you base your comparison on your actual requirements–not on the narrative each vendor tries to push, nor on the hype around their product. It is ultimately irrelevant how many features or apps an eCommerce solution offers if you only use a tiny fraction of them. **Technology is just a tool: your platform should fit your brand, not vice versa.**

A platform-agnostic agency is the best partner for this kind of project: they have the expertise to advise you, but they are not married to one specific solution, which gives them the freedom to offer you what they genuinely believe to be the best path forward.


## 3. Account for All the Expenses

Platform and transaction fees are a _significant_ part of any eCommerce brand’s P&L statement. When replatforming, you should clearly understand the costs you’ll incur under the new tech stack if you don’t want any unpleasant surprises.

Unfortunately, many brands jump the gun here and only account for the most apparent and immediate costs, such as their platform’s transaction fees in the first year. As a result, they neglect other variables that are not as visible but equally important, only to get burned by their new vendor once it’s too late to go back.

When approaching a re-platform, we typically categorize the costs as follows:

* **License fees:** this is how much you’ll pay your vendors for access to their services. Most brands only include the cost of their eCommerce platform here, but you should also account for any third-party apps and services you will need.
* **Transaction fees:** these are the fees you pay on your payments, and they typically have fixed and variable components. Some platforms have integrated payment gateways with lower transaction fees, while others will require you to work with a third party.
* **Maintenance fees:** we would all love to use an eCommerce platform that requires zero maintenance, but that is rarely the case. While you can’t calculate precisely how much design and development effort you’ll need with your new platform, you should make an educated guess and understand how that compares with your current setup.
* **Replatform fees:** how much will it cost to execute the replatform? Assuming that your goal is reducing engineering spend, how long will it take you to recoup that initial investment under the new platform?

When evaluating these costs, you also want to understand how they will change as your brand grows: what would they look like at 2X your current scale? Does pricing grow linearly, more than linearly, or less than linearly? Will there be room for negotiation, or are you locked into this commercial structure forever? Does the new vendor have any minimum commitments?

Every platform is unique, but do your best to make an apples-to-apples comparison that clearly outlines the total cost of ownership and any pros/cons associated with each option.

## 4. Approach the Work Incrementally

Switching over to the new platform will require a Big Bang Release, where you switch your brand to your new tech stack almost overnight. This approach is typically frowned upon in software development: the more changes you’re introducing simultaneously, the more you increase the chance that something will go wrong.

The bad news is that Big Bang Releases are somewhat unavoidable with most replatforms. The good news is that there are several approaches to minimize the amount of uncertainty associated with them. In general, if you can do something _before_ you finalize your transition to the new platform, you should.

Here are a few techniques we typically adopt:

* Work closely with your in-house team or external partner to demo and test their work as often as possible. You don’t want the team to work in isolation for three months and then do your testing in one go: you’re bound to miss something or discover significant problems once it’s too late to do anything about them. Better yet, have your entire team do QA: you’ll be surprised how much more stuff you can find as a group!
* If you need to make any changes to integrations or external systems to make them compatible with your replatform, see if you can apply them beforehand in a way compatible with both the old stack and the new one. This typically applies to ERPs, WMSs, and 3PLs, but you can generalize it to other vendors.
* Test your data migrations ahead of time and continue to execute them continuously in the days leading up to the launch. That way, on launch day, you will only need to migrate a small portion of your data rather than all of it.
* Create checklists for what you will do before, during, and after the replatform. Launch day is incredibly stressful, so it’s essential your team doesn’t have to think too much about what they’re going to do.

These are just some ideas, and your mileage may vary depending on your setup and the complexity of your architecture. The rule of thumb is that you want to work in small increments and do the bulk of the work upfront, so you only need to pull the trigger on launch day.

You can also check out [this article](https://nebulab.com/blog/ecommerce-agency-productivity) we published about how to optimize your agency’s or digital team’s productivity. All of those strategies also apply to replatform projects!

## 5. Resist the Urge to Redesign

If there is one thing you take away from this article, let it be this: do NOT do a rebrand or redesign at the same time you’re doing a replatform. After over a decade of working with eCommerce brands of all sizes, we have witnessed so many failed attempts at this that we strongly discourage this practice.

There are several reasons why a redesign might be bundled together with a replaform. In our experience, it’s usually a combination of the following factors:

1. Most brand executives are visual people. During a replatform, they get understandably excited and come up with a million potential improvements to the customer experience, which often turn into a full-blown redesign.
2. The byproduct of #1 is that, in larger companies, the person sponsoring the replatform often feels the need to justify the investment to their boss through a tangible artifact, such as a rebrand/redesign. This gives them a clear “thing” to point to when someone asks them where all that money went.
3. Unfortunately, some eCommerce agencies do redesigns along with replatforms to increase the scope of the engagement, and so that the final result can be more easily turned into a compelling case study.

As we already mentioned, this is almost always a bad idea. Replatforms are complicated and risky, so you want to keep their scope as small and controlled as possible. Redesigning your website while uprooting its tech stack dramatically increases the risk of something going wrong during or after the launch. It also makes it much harder to isolate and measure the business impact of specific changes to the customer experience.

We suggest keeping the new website as similar as possible to what you had before. After you launch the replatform, you’ll have plenty of time to fully leverage the capabilities of your new tech stack, so there’s no reason to rush it.

## 6. Prioritize the Scary Stuff

Remember that Big Rocks, Pebble, Sand categorization we talked about earlier? That’s not just a way to map your business requirements, but it’s also an excellent mental model to keep in mind when prioritizing the different features involved in your replatform:

1. Big Rocks are the most critical problems to solve and carry the highest risk and uncertainty, so you want to get them out of the way as early as possible.
2. Pebbles are essential but less risky–you want to get them done and tested early, but not before you’re done with the Big Rocks.
3. Sand is irrelevant: while some of these features are important to your business, they’re also quick and easy to implement and can be left for last.

Unfortunately, we often see things being approached in the opposite order. Because it’s easier and faster to make progress on Sand than on Big Rocks, they focus on the lowest-hanging fruit while neglecting the big, scary problems screaming at them.

One brand we spoke with in the past, which was heavily subscription-based, reached the last week of their replatform without having done any work on their subscription engine yet. When they finally focused on it, they realized the provider they had picked wouldn’t be able to accommodate their needs, and they had to cancel the launch and go back to the drawing board.

To keep your team focused, it can be helpful to appoint a Product Owner/Project Lead. This person, who ideally has project management experience and understands your brand inside out, will be responsible for keeping track of the project’s progress and ensuring the team is prioritizing the work correctly.

One last word of warning here: remember that perfect is the enemy of good. Just like with the redesign, you’ll have plenty of time to improve your online store after the launch, so don’t get bogged down in pursuing tiny optimizations at the expense of bigger achievements.

## Launch and Celebrate!

If you follow the tips above, launch day should be much less stressful than it could have been. Just follow your checklists on launch day, sit back, and celebrate!

Besides that, now is the time you can fully unleash the true power of your new eCommerce stack. As always, make sure to move intentionally and be data-informed–[establishing a lightweight Product Management practice](https://nebulab.com/blog/ecommerce-product-management) can do wonders in ensuring you’re not getting ahead of yourself, but working on features that will actually move the needle.

We hope we managed to shed some light on what is typically a long and confusing process for any brands that go through it!

If you need additional help with your replatform, [don’t hesitate to reach out!](https://nebulab.com/contact-us) Our team works with a variety of eCommerce platforms. They would be more than happy to advise you on the best choice for your brand and guide you through the entire implementation and launch process.

How To Nail Your eCommerce Replatform

Daniel Bergholz

If you have been working with Shopify’s Hydrogen framework for some time, you might still have some scars after the
[migration from Hydrogen v1 to Hydrogen v2](https://nebulab.com/blog/shopify-hydrogen-v2-updates).

One of the major changes in Hydrogen v2 was the transition from a custom-built React framework to
[Remix](https://remix.run/), a relatively new framework that is seeing a lot of traction thanks to its streamlined
developer experience, its reliance on Server-Side Rendering and its deep focus on web standards.

Remix was a significant improvement over Shopify’s in-house React framework, and allowed Hydrogen stores to benefit
from a much larger ecosystem of Remix docs, plugins and system integrators. We’ve discussed the benefits at length in
[our blog post covering the migration](https://nebulab.com/blog/shopify-hydrogen-v2-updates).

Unfortunately, the migration process from Hydrogen v1 to Hydrogen v2 was also incredibly complex. So much so, that many
large brands were better off re-building their storefront from scratch with Hydrogen v2 rather than attempting to port
their existing codebase. This caused a lot of discontent and frustration with Shopify’s decision, which didn’t seem to
fully appreciate the complexity of maintaining a complex headless architecture.

Now, it _feels_ like history might be repeating itself: Remix just announced a new major release. Remix v2 comes with
several new features and improvements to the developer experience that Hydrogen developers will also benefit from.
However, Hydrogen teams are also worried that the transition to Remix v2 might be their latest time-suck and source of
frustration.

But is that really the case, or are things better this time around?

In the past few weeks, we’ve been following the Remix community and trying to unpack the implications of this release
for Hydrogen. Let’s see what this release actually means for you, and how you can make the best of it!

## What’s New in Remix v2 for Hydrogen Devs?

Let’s start by taking a look at the changes and new features in Remix v2 that are most relevant for Hydrogen developers.

Keep in mind that you can always read the [release announcement](https://github.com/remix-run/remix/releases/tag/remix%402.0.0)
if you want to see the complete list of changes!

### New Dev Server with HMR and HDR

If you’ve used a more established React framework such as Next.js, you’re probably familiar with HMR even though you
might not know the acronym. HMR, which stands for Hot Module Replacement, is the feature that allows the page to update
instantaneously and reflect any changes you make to your code. It’s a handy functionality when you’re actively
developing a new page, or making small visual tweaks that you want to preview in real time.

Historically, Remix did not offer support for HMR: that meant you had to manually refresh the page whenever you made
a change to your client-side or server-side code, which was old-school and time-consuming.

Luckily, that’s not the case anymore! Remix v2 ships with a new dev server that supports HMR and Hot Data Reloading
(HDR), the equivalent of HMR for server-side code. Whenever you make a change to your Hydrogen app, it will be
propagated immediately to your browser. Client-side state is also maintained, so that you can continue interacting with
the app without restarting any user flows from scratch (e.g., if you’re in the middle of checkout).

It has support for hot module replacement (HMR) and hot data reloading (HDR). The announcement is available
[on YouTube](https://www.youtube.com/watch?v=79M4vYZi-po).

On earlier versions of Remix, whenever there was a code change, you would have to manually refresh the page to see the
new changes (pretty old-school tech). Now, that is unnecessary and HMR will not reset client-side state between updates.
And HDR can be described as HMR for data loaders. With HDR you can make changes to your server code and see those
updates reflected in your UI immediately without resetting client-side state, just like HMR.

### Native Support for PostCSS and Tailwind and PostCSS

As you probably know, Hydrogen uses [Tailwind](https://tailwindcss.com/) as the default CSS framework.

Unlike more traditional CSS frameworks (such as Bootstrap), Tailwind relies heavily on CSS post-processing to generate
your final CSS build: it scans all your files, understands which Tailwind classes need to be generated, and then
generates just the classes you need. This allows you to minimize the amount of CSS you’re shipping to the client while
also allowing you to do incredible things, like attaching [arbitrary CSS properties](https://tailwindcss.com/docs/adding-custom-styles#arbitrary-properties).

Before Remix v2, you would have to run any CSS transformations in a separate process, e.g. with
[Tailwind’s CLI interface](https://tailwindcss.com/blog/standalone-cli), then import the final CSS file into your Remix
app. This worked, but wasn’t really a smooth development experience.

Remix v2 adds out-of-the-box support for [Tailwind directives and PostCSS](https://remix.run/docs/en/main/start/v2#built-in-postcsstailwind-support),
a popular CSS processor that Tailwind integrates natively with. If you’re using Hydrogen, all the relevant configuration
is generated for you: simply bootstrap your app, and your Tailwind styles will just start compiling automagically!

Check out Remix’s documentation about [PostCSS](https://remix.run/docs/en/main/styling/postcss) and
[Tailwind](https://remix.run/docs/en/main/styling/tailwind) for more details.

### Server-Side Streaming with `defer`

This one is a game-changer. Remix v2 aims to provide first-class support for React 18's SSR streaming capabilities
through the `defer` helper.

When you return a `defer` function call in a route loader, you are initiating a streamed response. This is very
useful when serving lower-priority data that may take longer to load. After all, you don’t want your users to wait on
slow data if more important content is ready to display on the page!

Here’s an example of what streaming looks like on the server:

```javascript
import { defer } from "@remix-run/node";

export async function loader ({ request }) {
  // Product info query is small, cached aggressively, ad
  // high priority for the user. Let’s go ahead and let it
  // resolve since it’s fast!
  let productInfo = await getProductInfo (rewquest);

  // Product reviews query is large and cache is more lax.
  // Let’s initiate the query but not wait for it to resolve.
  let productReviewsPromise = getProductReviews (request);

  // With defer, we initiate a streaming response. This allows
  // the user to access the resolved data (`productInfo`) as
  // soon as it’s available, while the unresolved product
  // reviews are loaded in the background.
  return defer ({
    productInfo,
    productReviewsPromise,
  });
}
```

The corresponding client-side code would then leverage the `Await` component, which is built on top of
[React’s `<Suspense />` API](https://react.dev/reference/react/Suspense):

```javascript
import { Await } from "@remix-run/react";

function ProductRoute () {
  let {
    // Product info has already resolved. Render immediately!
    productInfo,
    // Product reviews might not be ready yet 🤔
    productReviewsPromise,
  } = useLoaderData ();

  return (
    <div>
      <h1>{productInfo.name}</h1>
      <p>{productInfo.description}</p>
      <BuyNowButton productId={productInfo.id} />
      <hr />
      <h2>Reviews</h2>
      <React.Suspense fallback={<p>Loading reviews…</p>}>
        <Await resolve={productReviewsPromise} errorElement={<ReviewsError />}>
          {(productReviews) =>
            productReviews.map ((review) => (
              <div key={review.id}>
                <h3>{review.title}</h3>
                <p>{review.body}</p>
              </div>
            ))
          }
        </Await>
      </React.Suspense>
    </div>
  )
}

// Error fetching the data? Slow connection and timed out?
// Show an error message *only* for reviews. The rest
// of your product UI is still usable!
function ReviewsError () {
  let error = useAsyncError (); // Get the rejected value
  return <p>There was an error loading reviews: {error.message}</p>;
}
```

This was a framework-agnostic example, but Hydrogen is already leveraging `defer`. On the home page, for instance,
recommended products are streamed rather than being loaded immediately:

```typescript
export async function loader ({context}: LoaderArgs) {
  const {storefront} = context;
  const {collections} = await storefront.query (FEATURED_COLLECTION_QUERY);
  const featuredCollection = collection.nodes[0];
  const recommendedProducts = storefront.query (RECOMMENDED_PRODUCTS_QUERY);

  return defer ({featuredCollection, recommendedProducts});
}
```

For more examples of how Hydrogen leverages Remix features to optimize data handling, you can take a look at
[this article](https://hydrogen.shopify.dev/update/improving-data-handling-in-hydrogen-and-remix).

### Flat Routing by Default

Older versions of Remix use subfolders to nest route segments. This leads to a lot of directory nesting, and also makes
it harder to navigate the directory tree.

Remix v2 embraces [flat routing](https://remix.run/docs/en/main/start/v2#file-system-route-convention) instead. With
flat routing, all your routes are in the same directory, which makes it easy to find them at a glance. For example,
here’s the new folder structure in a Hydrogen application based on Remix v2:

![](https://cdn.sanity.io/images/kqgmf0g2/production/59ae846180e55976494ef64fb35b7ee854107044-698x1370.png?fit=clip)

There’s a bit more to it, so we encourage you to check out [Remix’s documentation](https://remix.run/docs/en/main/start/v2#file-system-route-convention)
about the change to fully understand the new folder structure.

Since not everyone will love this change, you can also maintain the current approach by installing the
`@remix-run/v1-route-convention` package and adding the following to your `remix.config.js`:

```javascript
const {
  createRoutesFromFolders,
} = require ("@remix-run/v1-route-convention");

/** @type {import ('@remix-run/dev').AppConfig} */
module.exports = {
  future: {
    // makes the warning go away in v1.15+
    v2_routeConvention: true,
  },

  routes (defineRoutes) {
    // uses the v1 convention, works in v1.15+ and v2
    return createRoutesFromFolders (defineRoutes);
  },
};
```

## How to Upgrade Your Hydrogen Application to Remix v2

Now, this is the part you were all waiting for! How difficult is it to upgrade an existing Hydrogen application to Remix
v2? Luckily for you, not very difficult.

The typical approach for performing major upgrades to your application’s dependencies typically involves creating a
separate, long-lived feature branch, working on the upgrade in isolation, and then releasing it all in one go.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a7da987d49c9126fa8f5bc3dd60f94bbf867eea6-1516x634.png?fit=clip)

This approach, which is still very widespread, has several drawbacks:

- It is time-consuming, because it requires a lot of work and frequent rebases.
- It is prone to error, because you’re releasing a lot of changes in one deployment.
- It is all-or-nothing, because it prevents you from adopting new features before the upgrade.

Remix aims to fix this problem through [Future Flags](https://remix.run/docs/en/main/start/future-flags). Future flags
allow developers to incrementally adopt new features and then seamlessly upgrade their application, eliminating the need
for long feature branches and scary deployments.

Conceptually, the way they work is very simple: the Remix team releases Remix v2 features in Remix v1, but puts them
behind a feature flag that you need to manually enable in your Remix configuration. Then, when Remix v2 is released, the
Remix team simply removes all future flags and turns them into default behavior. This allows you to integrate one
feature at a time as it’s released by Remix, rather than doing it all in one pass.

![](https://cdn.sanity.io/images/kqgmf0g2/production/79ff3d1e16ca4fb2421871fa9cce3b5ba6a56599-1999x441.png?fit=clip)

For instance, here are the future flags for Remix v2:

```javascript
/** @type {import ('@remix-run/dev').AppConfig} */
module.exports = {
  //…
  future: {
    v2_dev: true,
    v2_meta: true,
    v2_headers: true,
    v2_errorBoundary: true,
    v2_routeConvention: true,
    v2_normalizeFormMethod: true,
  },
};
```

If you are on the latest version of Remix v1, your `remix.config.js` looks like the one above, and you’re not getting
any errors, you should be able to safely upgrade to Remix v2 by following the [official upgrade guide](https://remix.run/docs/en/main/start/v2).

If you haven’t enabled those future flags yet, then we strongly recommend doing so in the next few weeks so that you
can have a smooth upgrade path in front of you.

Note that the Hydrogen team still needs to officially release support for Remix v2, but thanks to future flags,
most of Hydrogen’s code is already compatible. All you need to do is upgrade the dependency in `package.json`, remove
the future flags in `remix.config.js`, and you should be good to go!

## What’s Next for Remix and Hydrogen?

In our work so far, we found the developer experience offered by Hydrogen through Remix is miles ahead of what we had in
Hydrogen v1. With a few lines of code, it’s possible to develop rich e-commerce experience while also abiding by web
standards and following modern UX practices. Because of that improvement, we’re very excited for the future of this
synergy!

The Remix team recently [announced](https://remix.run/blog/open-development) that they want to be more transparent about
their plans for the framework, but the [public roadmap](https://github.com/orgs/remix-run/projects/5) doesn’t offer a
lot of information yet. That means it’s still early to tell what other features might be coming up that Hydrogen
developers can benefit from.

One initiative on our radar is the [work](https://remix.run/blog/remix-v2#what-about-rsc) done by the Remix team to
integrate React Server Components (RSC). Unfortunately, this will take some more time, as RSC are still unstable and
won’t be included in Remix just yet as a result.

If you were waiting for more features or stability in order to start using Hydrogen, today is the best time to give it a
try! We’re sure you will be pleasantly surprised.

What Does Remix v2 Mean for Shopify Hydrogen Developers?

At the end of 2022, the entire frontend community was surprised by an unexpected announcement: [Shopify acquired Remix](https://shopify.engineering/remix-joins-shopify). At first glance, this news offers little information; after all, Shopify is famous for investing many resources into open-source projects. However, after further research, the reason for this merger became clear: Remix is deeply aligned with Shopify’s new framework: Hydrogen.

Shortly after the big news, the dev team behind Hydrogen [made another announcement](https://hydrogen.shopify.dev/roadmap/): the entire framework was being re-created from scratch using Remix, thus giving birth to Hydrogen v2. While the upgrade path will likely be a struggle for existing Hydrogen v1 users, Hydrogen v2 offers several benefits over its predecessor.

In this article, we’ll look at some of the most significant enhancements Hydrogen v2 brings to the developer experience, what they mean for your user experience, and how you can start adopting them in your storefront.

## A Brief Primer on Remix

To fully comprehend Hydrogen’s latest changes, we must first understand Remix.

For those unfamiliar with it, Remix is an up-and-coming Javascript framework based on React. It was developed by Kent C. Dodds, Ryan Florence, and Michael Jackson, all well-known contributors to the Javascript open-source community.

Unlike the previous generation of React frameworks such as Next.js, Remix is full-stack, monolithic, and fully server-side-rendered, and it will feel like a breath of fresh air to all the Ruby on Rails and Laravel lovers. In fact, Remix’s primary goal is to merge the benefits of the “old Web” with the smooth developer experience React offers. This way, developers get higher productivity, simpler code, better SEO, less backend-frontend communication overhead, smaller client bundles, and near-instantaneous page transitions.

![](https://cdn.sanity.io/images/kqgmf0g2/production/030082583dd37bf225378d98322d8b1993cf3e0b-2960x2400.png?fit=clip)

When developing the first version of Hydrogen, Shopify created a framework very similar to Remix in spirit: it was React-based, but it was also rendered on the server. This was a surprising choice back in the early days of Hydrogen, but it did make a lot of sense in retrospect: anyone who has tried to implement an eCommerce storefront quickly found that the dynamic nature of eCommerce doesn’t play well with static site generation and client-side rendering.

In October 2022, Remix announced that Shopify was acquiring it. As part of the deal, Shopify will offer continuous support to Remix’s authors to continue developing the framework, and Remix is becoming the React framework powering Hydrogen. On their side, Hydrogen’s development team can now delegate most of the core framework functionality to Remix, focusing only on Hydrogen-specific functionality.

## The Main Changes in Shopify Hydrogen v2

Even though the Shopify developer community (and Shopify themselves, [in some places](https://github.com/Shopify/hydrogen/blob/2023-04/packages/hydrogen/CHANGELOG.md#202317)) dubbed this release “Hydrogen v2”, this isn’t technically correct: Hydrogen simply follows calendar versioning, with each version number being a combination of the date and month of the release (e.g., v2023.1.0). However, for the sake of simplicity, we will refer to “Hydrogen v2” as the version of Hydrogen that uses Remix.

As you might expect, this release introduces _a lot_ of changes. In fact, pretty much everything in the framework has changed, meaning developers with an existing Hydrogen storefront have a whole bunch of rewriting to do.

### Retrieving Data with Loaders

The most significant change–which will affect pretty much every route in your project–is the introduction of Remix’s `loader` function.

The `loader` function is where all of your data retrieval logic is stored. The `useShopQuery` and `useQuery` hooks from Hydrogen v1, responsible for querying the Shopify Storefront API, have been replaced with `loader` in Hydrogen v2.

For example, imagine building a product detail page with a product options selector. In a typical React storefront, you would need to store the selected options in a state entry:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e553a7b7b1f1e0d77e3cd95a9ecef7a1893b29c9-1200x520.png?fit=clip)

The problem with this implementation is that this component also needs to change the URL whenever a new variant is selected, so that users can easily bookmark or share the URL to the correct product variant. Unfortunately, there is no “native” way of achieving this with React. You would need to create a function that alters the URL when the user changes their selection.

With Remix, just like Ruby on Rails or Laravel, you can solve this by simply taking advantage of Web fundamentals. In this case, whenever the user selects a new product option, you simply direct them to a new URL, and the `loader` function gets executed again, querying the desired product variant from the Storefront API.

![](https://cdn.sanity.io/images/kqgmf0g2/production/3217fe54a31e57a20a6240808dd00e4937c4f7eb-1200x856.png?fit=clip)

The benefits of this new implementation are clear: we achieve the same outcome with less code and fewer abstractions to learn.

This approach was used to refactor all the major components in Hydrogen: the cart, analytics, SEO, and session management were rebuilt from scratch, resulting in a much more straightforward developer experience and a less steep learning curve!

[Learn more about the `loader` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/loader)

### Mutating Data with Actions

While the `loader` is used to _retrieve_ data, the `action` function is to _mutate_ data. As a consequence of segregating business logic into loaders and actions, you can now remove a bunch of code, especially client-side logic and state.

As an example, take a look at what the default `AddToCart` component looks like in the Hydrogen v1 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/253be981f9a0861351e4e2bcba39e77df56fec53-1374x2904.png?fit=clip)

And now, look at the same component in the Hydrogen v2 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/5c38c039f5c5132d9b9ba34c6d19d0b0075b7f0b-1424x1786.png?fit=clip)

As you can see, a lot of state management and querying logic has been removed in favor of a more straightforward implementation that relies on Web fundamentals such as... Web forms! This simplifies your code and makes your online store more resilient to network issues and more accessible to screen readers and old devices.

[Learn more about the `action` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/action)

### Handling Errors with Error Boundaries

A common and annoying problem with React applications is isolating errors. Typically, when you get any error on the frontend, the whole UI breaks, and the website becomes unusable. This is obviously not a desirable experience for our customers.

By taking advantage of Remix’s [nested routes](https://remix.run/docs/en/1.16.1/guides/routing#what-is-nested-routing), you can use [nested error boundaries](https://remix.run/docs/en/v1/guides/errors#nested-error-boundaries). If you export an error boundary function from a nested route and an error occurs, the error will be isolated, and the rest of your application will remain usable. This allows you to offer the best possible UX, even when things go wrong:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e73f3849c1e52c9a44c721ff4b43976455174ab8-1207x1685.png?fit=clip)

[Learn more about error handling in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/errors)

### Speeding Up Page Loads with Streaming

By using Remix’s [defer](https://remix.run/docs/en/1.16.1/guides/streaming#using-defer) function, you can easily decide which parts of your page should be rendered right away and which parts can be streamed after the page has loaded:

![](https://cdn.sanity.io/images/kqgmf0g2/production/d1fc77778b2760be478d391326acc7ede28f1abe-1207x1685.png?fit=clip)

This technique allows you to easily defer the loading of lower-priority parts of your UI, such as a “Related products” section on your PDP, making for a better user experience and faster loading times.

[Learn more about streaming in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/streaming)

### Speeding Up User Interactions with Optimistic UI

Optimistic UI is a powerful technique that lets you completely hide loading states from the end user. For instance, when a user clicks on your Add to Cart button, rather than waiting for the cart to be updated on the server, you might immediately display the new item in the user’s cart. Then, if an error occurs, you can revert the state and display an error to the user:

![](https://cdn.sanity.io/images/kqgmf0g2/production/1cdb09cad49d184358eb840920173250a2061bc1-1250x800.png?fit=clip)

While not available yet, Hydrogen’s development team plans to adopt optimistic UI in all the standard components. Because Hydrogen is powered by Remix, you will also have the opportunity to use the same pattern in any custom user interactions you offer on your storefront.

[Learn more about optimistic UI in the Remix guides.](https://remix.run/docs/en/1.16.1/tutorials/jokes#optimistic-ui)

### Oxygen Is now Available to All Shopify Plans!

Although there was no official announcement, this is massive news for all Shopify developers! Hydrogen’s official deployment platform, [Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen), which was only available to Shopify Plus users, is now available to all Shopify plans.

Oxygen is an excellent tool for engineers who want a seamless deployment and hosting experience. By keeping your storefront within Oxygen, you can not only reduce your infrastructure costs, but also have access to a fantastic developer experience that includes:

* Preview environments for testing changes in isolation.
* Custom environments (e.g., if you want a staging area).
* Version control and GitOps for your storefront.
* A Content Delivery Network (CDN) powered by Shopify.
* Support for both backend and frontend code.
* CI/CD via GitHub Actions and the Hydrogen channel.

If you’re familiar with Vercel, you’ll find that Oxygen offers a very similar development experience, but more accurately tailored to the needs of Shopify developers.

## Migrating from Hydrogen v1 to Hydrogen v2

If you are using Hydrogen v1 today, there’s a [handy migration guide](https://shopify.dev/docs/custom-storefronts/hydrogen/migrate-hydrogen-remix) in the Hydrogen docs that you can follow to upgrade your storefront.

The process takes a lot of effort, but the guide is comprehensive and accurate, so you should be able to upgrade your Hydrogen app by simply following the steps outlined.

## Is Hydrogen Ready for Production Use Yet?

That depends on your risk tolerance!

On a technical level, both Hydrogen and Oxygen are most definitely production-grade products, and they are being used successfully in the wild by large Shopify stores such as [Allbirds](https://hydrogen.shopify.dev/case-studies/allbirds). The developer experience is pleasant and powerful, and Shopify’s hosting infrastructure will easily handle any production load you throw at it.

On the other hand, it’s unclear whether Hydrogen will see any more extensive refactorings, such as the one we’ve just witnessed. As an example, [Remix v2](https://remix.run/docs/en/main/pages/v2) will be released soon, bringing many improvements over its predecessor, but also requiring developers to upgrade to a new API and file naming convention. These changes will most likely affect Hydrogen users as well. It’s also unclear what synergies Shopify will create between Hydrogen and [Commerce Components](https://www.shopify.com/commerce-components), but we expect some movement there.

![](https://cdn.sanity.io/images/kqgmf0g2/production/e038f0246b07a894d83a8ae5cb1d3fe545d2bc6a-2960x2335.png?fit=clip)

Another factor to consider is how long it will take for the Shopify app ecosystem to catch up to Hydrogen’s philosophy. While some Shopify apps don’t need to worry about the frontend at all, others will have to expose an API or JavaScript SDK of some sort to be usable with a headless commerce architecture. We expect the situation to improve over the coming years, but there’s still a long way to go, and many Shopify apps today cannot be used with Hydrogen.

Overall, Hydrogen is well worth a try if you have the engineering firepower. It solves a significant number of problems for Shopify developers and gives brands unmatched flexibility in building a custom storefront, allowing them to create shopping experiences that would be very hard to replicate with Liquid themes.

However, if you’re a small brand and don’t have the resources to invest in experimental technology, you’re probably better off sticking with Liquid themes until Hydrogen becomes a true first-class citizen in the Shopify ecosystem.

Shopify Just Released Hydrogen v2. What’s In It for You?

While the total penetration of headless commerce in the US is still low, we have witnessed an increase in headless builds in recent years. And even though [we don’t believe headless is the end-all solution to all eCommerce problems](https://nebulab.com/blog/headless-commerce), we think it’s about time the industry realized the power of this architecture and started using it responsibly.

The only way for Shopify users to go headless for a long time was to implement their own single-page application from scratch, using a JavaScript library such as React (and hopefully a framework, such as Next.js). Shopify does provide SDKs to make the API integration work slightly more manageable, but that was about it: until recently, there was very little being done for performance, state management, personalization, or SEO.

In November 2021, Shopify released a developer preview of [Hydrogen](https://hydrogen.shopify.dev/), their new framework meant to address precisely these problems. Here at Nebulab, we’ve recently had the chance to take Hydrogen for a spin, and we want to share our learnings.

## What is Hydrogen?

Hydrogen is an open-source, React-based framework that can be used to build custom storefronts on the Shopify platform. It provides a lot of useful functionality:

* A sensible structure for your application code.

* eCommerce-specific components and pages.

* An SDK and hooks to interact with Shopify’s GraphQL-based [Storefront API](https://shopify.dev/api/storefront).

* It uses [Tailwind CSS](https://tailwindcss.com/) for styling.

* It’s optimized for high-performance builds.

Combined, these features almost entirely eliminate the amount of boilerplate code engineers need to write to build their storefronts and allow engineers to spend most of their time on functionality that truly moves the needle.

![Shopify Hydrogen website](https://cdn.sanity.io/images/kqgmf0g2/production/9865cb4da04e7cd861e38c97cc7015d8ea7a1e22-2560x2512.png?fit=clip)

## What are the pros of using Hydrogen?

For Shopify stores that want to go headless, Hydrogen is a huge help. As we’ve mentioned, it abstracts away all the complexity of integrating with the Shopify API and developing your storefront’s skeleton: all you need to do is clone the Hydrogen [demo store](https://shopify.dev/custom-storefronts/hydrogen/getting-started/templates#demo-store-template), configure it, then focus on styling and custom functionality. This alone is a huge productivity boost, and the developer experience has been outstanding in our experiments.

It’s also important to note that Hydrogen is officially developed and supported by Shopify, which should provide peace of mind to brands looking for a stable, robust solution that’s not going anywhere. While some Shopify-specific Next.js templates already existed before Hydrogen, they were mostly small, community-sponsored projects, which made them unsuitable for enterprise use.

## What are the cons of using Hydrogen?

Seasoned developers know that productivity comes with a hidden cost: the more a tool tries to abstract away technical complexity, the more opinionated it is. When it comes to Hydrogen, it’s exceptionally opinionated:

* It uses React server components.

* It uses streaming server-side rendering (SSR).

* It has built-in components, hooks, and caching mechanisms.

* It’s heavily coupled with Shopify’s Storefront API.

* If you need complete control over your React application, Hydrogen is most likely not a good candidate for you.

You should also know that some of these features are bleeding edge in the React ecosystem, and because Hydrogen is tightly coupled with Shopify, the community around it is still relatively small. Hydrogen brands can expect to have a harder time finding online resources and support, and they will have to tap into a smaller pool of agencies and engineers than if they used a more popular framework. That said, much of that will likely change as Hydrogen gains popularity.

Finally, most Shopify Apps and plugins were built to integrate with Liquid templates and won’t be compatible with Hydrogen (or other headless architectures, for that matter). If you rely heavily on specific apps and your app doesn’t provide an API your engineers can integrate with, you’ll need to switch to a headless-friendly alternative or build the functionality yourself.

## Can Hydrogen be used without Shopify Plus?

It’s complicated. The official answer is yes: since Hydrogen is an open-source project whose source code is available to anyone, and because none of the API endpoints it uses are restricted to Shopify Plus customers, at first glance, the framework can be used without Shopify Plus.

In reality, things are more nuanced.

![Shopify Oxygen documentation](https://cdn.sanity.io/images/kqgmf0g2/production/a893aabf4ed6f21f992598100837e4856353c79f-2560x1620.png?fit=clip)

First of all, there’s the matter of hosting your Hydrogen application. Plus users can host their Hydrogen app on [Shopify Oxygen](https://shopify.dev/custom-storefronts/oxygenhttps://shopify.dev/custom-storefronts/oxygen), Shopify’s proprietary hosting solution, which provides native support for directing users who visit your Shopify domain to your Hydrogen storefront.

If you don’t use Shopify Plus, you should still be able to deploy your Hydrogen app to other platforms, but it won’t be a painless experience. For example, Vercel has published a blog post announcing the availability of a [zero-configuration deployment for Hydrogen](https://vercel.com/changelog/hydrogen-projects-can-now-be-deployed-with-zero-configuration). But when we tested it, we had to manually tweak the environment variables used by Hydrogen to match the names used by Oxygen. This was a minor inconvenience overall, but it shows how support for Hydrogen is still in its infancy.

Once you’ve figured out the hosting, it’s time to deal with domains and DNS records. If you manage your domains through Shopify, Shopify will attempt to redirect any requests to your [myshopify.com](http://myshopify.com/) domain to your Hydrogen storefront, which will completely break the checkout. This could be easily solved by using a [routing domain](https://help.shopify.com/en/manual/domains/domain-type/routing-domain) which, ironically, is only available to Shopify Plus customers. (When we reached out to Shopify engineering about this catch-22-esque paradox, they seemed utterly taken aback by this realization.) The current solution is to set up your Liquid storefront to redirect to your Hydrogen storefront via JavaScript, which is far from ideal.

Another aspect to consider is support: in our experience, if you’re not a Shopify Plus customer, you’re only going to get extremely limited technical support from Shopify, with most requests being redirected to Shopify’s Discord community. No one in the Discord community seems to have much experience with Hydrogen, except for Shopify’s own employees, whose presence in the community is very erratic.

To be fair, Shopify did tell us that they are working to address these challenges and make Hydrogen truly available to non-Plus customers. However, _when_ this will happen exactly is unknown.

To sum it up, if you’re not on Shopify Plus and don’t have an experienced engineering team or agency backing you up, we would advise against using Hydrogen right now: you run the risk of spending weeks or months of development only to run into deal-breaking roadblocks.

![Shopify Discord](https://cdn.sanity.io/images/kqgmf0g2/production/ce5f2c4f4565702286b8a1df6cd0d17d418c8538-2560x2068.png?w=450)

## Who should be using Hydrogen?

Shopify’s Hydrogen framework is the perfect solution for online stores that are already running headless, or are planning to go headless, can count on a robust engineering team, and want to lean into a powerful, officially-supported solution that will spare them from boilerplate work. The developer experience is enjoyable, and most React engineers will be more than happy to work on a Hydrogen app.

If, on the other hand, you don’t have an experienced engineering team or don’t want to deal with the complexity that comes with a headless solution, Hydrogen is not a good choice: as much as it simplifies things, it will still require much more upkeep than a Liquid-based Shopify build.

At this point, Hydrogen is also a less-than-ideal solution for brands not on Shopify Plus due to missing functionality and limited support from Shopify. That is likely to change as the framework matures and becomes more widely available, so keep an eye out for any announcements from Shopify (and from us!).

If you’re considering going headless with Hydrogen or other frameworks, and are unsure of the implications, [feel free to reach out](https://nebulab.com/contact-us)! Our team has extensive experience and will help you make the choice that best supports your digital strategy.

Everything You Need to Know About Shopify Hydrogen

As funding for headless commerce platforms reached a staggering [$1.6 billion](https://www.forbes.com/sites/forbestechcouncil/2021/05/11/why-is-headless-commerce-getting-16-billion-in-funding/?sh=5322b28f513a) in 2021, these systems aren’t to be ignored. But how exactly do they compare to the so-called traditional “monolithic” eCommerce platforms, and when should you pick one over the other?

This guide will explore the headless commerce model, its benefits, how it differs from the all-in-one monolithic commerce system, and when it’s a good option for your brand.

## What is headless commerce and how does it work?

Headless commerce is an eCommerce architecture where the frontend layer, or presentation layer, is decoupled from the backend commerce functionality.

Before we continue, let’s review the key differences between the frontend and backend:

* **Frontend:** This is the user interface. Customers see and interact with the frontend, whether they’re accessing your eCommerce site, shopping app, digital kiosk or other shopping channels.

* **Backend:** The backend is the behind-the-scenes, technical side of an eCommerce store the customer doesn’t see. The backend includes the technologies and tools that run in the background to ensure customers can shop and [have smooth checkouts](/blog/one-page-checkout-with-spree).

In headless commerce, the frontend and backend systems communicate via Application Programming Interfaces (APIs). This approach allows you to update the frontend, the customer-facing part of your site, independently of the backend and even use different development frameworks. This separation of concerns offers several benefits which we’ll explore below.

Examples of headless eCommerce solutions are Commerce Layer, Swell, and Nacelle.


## 4 benefits of headless commerce

![Woman lying on a couch and using a laptop](https://cdn.sanity.io/images/kqgmf0g2/production/96998b94bc1edf8908d27f5af24b1a34e88c56a8-1200x797.jpg?fit=clip)

Platforms that adopt a headless architecture offer several benefits compared to monolithic, or so-called traditional eCommerce platforms. Here are the top four advantages.

### 1. Omnichannel capabilities

In an omnichannel eCommerce experience, customers can start shopping on one channel or device and transition seamlessly to a different channel while the brand retains key information: common examples are a customer completing their purchase online, but selecting in-store pickup, or a customer buying something in-store and having the order show up their online order history.

Headless commerce makes it easy to serve the [74% of shoppers](https://www.salesforce.com/content/dam/web/en_us/www/documents/research/salesforce-state-of-the-connected-customer-4th-ed.pdf) who use multiple channels to shop: because the same backend system can serve multiple storefronts, you can easily adapt customer touchpoints and shopping experiences to serve your eCommerce website, your mobile app, social media pages, and even physical locations. All will be completely integrated and feel seamless for your customers to interact with.

### 2. Technical flexibility

By decoupling backend and frontend, headless platforms allow your development team to pick the frontend stack, including third-party providers, that they’re most productive with. A headless architecture allows you to adopt your favorite content management system (CMS) to create rich editorial experiences, or elevate your storefront through progressive web apps (PWAs). This enables you to create engaging digital experiences that don’t face the limitations of traditional monolithic frontends.

When done right, headless architectures even allow you to refactor or completely replace entire parts of your backend with little to no impact on your frontend experience(s), which allows you to move and experiment much more quickly.

### 3. Superior personalization

Most monolithic eCommerce platforms severely limit your ability to personalize the customer experience by forcing you to work with proprietary templating language and preventing you from accessing customer data. With [80% of customers](https://www.epsilon.com/us/about-us/pressroom/new-epsilon-research-indicates-80-of-consumers-are-more-likely-to-make-a-purchase-when-brands-offer-personalized-experiences) indicating they prefer brands that offer tailored experiences, eCommerce personalization is now table stakes for modern brands.

Headless platforms allow you to not only leverage basic eCommerce data, such as a customer’s profile and order history, but even augment it with brand-specific data points of your own. This allows you to create shopping experiences that feel built for your customer, boosting customer engagement, conversion rates and AOV.

### 4. Blazing fast performance

Storefronts that leverage a headless eCommerce platform can typically be deployed as static sites and put behind a global content delivery network (CDN) such as Cloudflare. In the hands of a capable development team, this can lead to incredible performance that would be hard to achieve with a monolithic platform.

A 2019 study by Portent has found that improving your loading speeds can boost your conversion rates [anywhere from 1.5X to 2.5X](https://www.portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm)! If your eCommerce site loads slowly, you are leaving lots of money on the table—literally.

## 3 drawbacks of going headless

![Four programmers working at same office's table](https://cdn.sanity.io/images/kqgmf0g2/production/0afcfb4759febba635d79b5004c9a4cf4c8c2242-1200x800.jpg?fit=clip)

In some cases, a headless build can lead to an unnecessarily complex architecture that causes more problems than it solves. Evaluating which eCommerce platform to use for your business needs is a complex process that should take into account both short-term and long-term factors as well as your budget and internal capabilities.

Here are three drawbacks of headless eCommerce platforms.

### 1. Technical capabilities

Launching a headless storefront requires you to create an in-house engineering team or hire an eCommerce agency for the long term. Headless sites require more ongoing maintenance to keep the lights on: Dependencies need to be updated, infrastructure needs to be maintained, and the site needs to be continuously monitored for bugs and performance issues.

In our experience, this additional effort has its upsides: It forces brand operators to get into a continuous optimization mindset, where they’re constantly identifying and capitalizing on new technology and other opportunities that can improve the shopping experience. Monolithic platforms, on the other hand, encourage a less intentional set-and-forget approach, which is definitely easier to execute, but also worse positioned for long-term scalability.

### 2. Time-to-market (and cost!)

Headless builds are typically associated with slightly higher timelines than monolithic builds. Adopting a headless architecture requires a significant investment in an agency or an in-house development team that will build your storefront, and this process can take anywhere between 2 and 4 months, depending on the complexity of the build.

Conversely, launching a store on a monolithic platform can be a much faster process with more competitive pricing, if you’re willing to settle for a more standardized look and purchase experience. This can be an acceptable compromise for smaller mom-and-pop businesses, but certainly not for a direct-to-consumer (DTC) brand with large long-term aspirations.

### 3. Integration effort

Headless eCommerce platforms are very flexible because you have full freedom to implement your storefront however you want. Unfortunately, this also means that many of the integrations and plugins that you can use out of the box with a monolithic platform will require a bit more work to be integrated in a headless architecture.

If you want to add reviews to your headless eCommerce website, for instance, you’ll need to work with your designers and engineers to figure out what the experience should look like, where to place the reviews, when to ask for them etc., and then implement and test the new functionality.

Ultimately, this extra effort is a good thing: A headless system asks you to be more disciplined and intentional in how you modify your storefront. This will force you to approach all initiatives with a critical eye rather than jumping from trend to trend, but it can be frustrating if you’re used to installing a plugin and forgetting about it.


## The verdict: headless or monolithic?

![Woman holding a credit card and using a phone](https://cdn.sanity.io/images/kqgmf0g2/production/cb3e8d957a2c46acdf1eda32e9cecd9c5173bf13-1200x800.jpg?fit=clip)

The answer is: It depends on the use case. There’s no right or wrong answer.

While a headless commerce architecture has myriad benefits over monolithic architectures, it’s not ideal in all contexts. In certain scenarios, a headless commerce approach is the best way to build your vision and drive superior brand performance, while in others, you’re better off with a monolithic architecture that saves you time and money.

Headless commerce solutions might be right for:

1. **Brands that want to offer a consistent customer experience across channels:** Any brand that wants to deliver consistent customer experiences regardless of channels or devices should consider adopting this architecture.

2. **Brands that feel their current platform is too rigid and restrictive:** If you’ve ever felt your platform is limiting on the backend or frontend, it’s time to switch to a flexible headless setup.

3. **Brands that put personalization front and center:** If personalizing the shopping experience is critical for your brand’s strategy, then you should explore the capabilities that a headless build will unlock for your development team.

4. **Online stores that have slow-loading pages:** If sluggish pages have been a pain point for your eCommerce store, a headless architecture may be able to help by allowing you to leverage a more robust frontend ecosystem.

On the other hand, monolithic builds are a good solution for:

1. **Brands with limited technical know-how:** Headless commerce requires stronger technical capabilities which might not be everyone’s cup of tea. If you want to launch a commerce website without dealing with the underlying technicalities, headless is not for you.

2. **Brands with time-to-market or financial constraints:** If you’re on a tight timeline or a limited budget, a monolithic build will very often prove cheaper and quicker to launch than a headless counterpart.

3. **Brands that want ready-made functionality:** If you want to leverage ready-made features and integrations without thinking too deeply about how to integrate them in your shopping experience, a monolithic platform will give you more peace of mind.


## Need help picking the right platform?

![Entrepreneur using his phone and laptop](https://cdn.sanity.io/images/kqgmf0g2/production/97e367e0de824649a05070d381052e44e0ca20e4-1200x801.jpg?fit=clip)

Headless architectures allow teams to move faster, address changing consumer needs, improve the user experience, and capitalize on omnichannel opportunities, but they’re not ideal for all brands.

Nebulab can help your new digital brand pick the right eCommerce platform for a greenfield build, or help your established brand design the right tech stack for its next growth spurt. We offer full-service consulting throughout all stages of your eCommerce project.

[Reach out](/contact-us) to see how we can help you create a vision for your eCommerce experience.

Headless Commerce: The Good, The Bad, and The Ugly

One of the most important decisions you will make when launching your digital brand is which eCommerce platform you build your store with. Typically, there are three categories to choose from:

* **SaaS platforms** are online software solutions that handle all the complexity of building and running a store. In exchange for a recurring license fee, these tools provide a storefront your customers can access as well as a backend to to manage your store. They are by far the quickest and easiest solution to get started. Popular examples in this category are [Shopify](https://www.shopify.com/) and [BigCommerce](https://www.bigcommerce.com/).

* **Open-source platforms** are ready-made software packages that provide similar functionality to what you could get with a SaaS platform. Because they are open-source, these platforms can be customized, although many of them are not built for that. Furthermore, you have to host them in your own infrastructure. Popular examples are [WooCommerce](http://woocommerce.com/) and [Prestashop](https://www.prestashop.com/).

* **Open-source frameworks** are software solutions that provide the basic functionality you need to build your store. They vary in functionality and underlying technology, but most of them are built to create extremely custom experiences and provide a very high degree of flexibility, at the cost of a steeper learning curve and a larger upfront investment. Popular examples are [Solidus](https://solidus.io/) and [Saleor](https://saleor.io/).
The main difference between SaaS platforms and open-source platforms is the pricing model: SaaS platforms require paying a recurring license fees, while most open-source platforms are free. In terms of functionality, however, they are pretty similar, so we will instead focus on the differences between SaaS platforms and open-source frameworks.

## Cost of ownership

SaaS platforms have two main pricing models: you either pay a fixed fee every month/year, or a percentage of your store’s sales volume. This results in a pricing model that scales with your store, but **it also means you are paying money just to keep your store online instead of investing in its continuous evolution.**

Most open-source frameworks, on the other hand, are entirely free to use, but you need to hire a development team that will build, launch and maintain your store. While this model requires a larger upfront investment, **it’s also a better fit for those entrepreneurs who are serious about investing in the technology that powers their business.**

If you can afford a larger upfront investment and you expect your brand to scale seriously, going with an open-source framework will reduce your total cost of ownership while creating more opportunities than you could get with an off-the-shelf solution.

## Customization possibilities

SaaS platforms offer a great starting experience with no customization work needed. This is really helpful for people who are just getting their feet wet in the eCommerce industry: **if you don’t know how to create a good UX and just want to start selling, a SaaS solution will help you.** This kind of simplicity doesn’t come for free, though: **SaaS platforms are not always easy to customize, and in certain cases you are stuck with the default experience they provide.**

Going with an open-source framework means you’ll have to figure out more stuff by yourself, but **it also affords you the flexibility to customize each and every aspect of your store however you see fit,** allowing you to truly innovate the buying experience rather than being one more droplet in a sea of digital brands.

The most prominent online brands became memorable not just because of their products, but because of the experience they created around all brand interactions. **If eCommerce is an important channel for you, you need to start seeing yourself as an experience company,** and treat technology as a first-class citizen.

## Data ownership

**SaaS platforms, unfortunately, act by their very nature as middlemen between you and your customers.** Because you are not hosting your infrastructure when you adopt a SaaS solution, you lose direct access to a lot of potentially useful information. These platforms try to make up for the lack of data ownership by providing out-of-the-box reporting tools, but they often fall short of brand expectations.

**With an open-source framework, you will always have complete access to all the data generated by your store.** This data can be used in any way you see fit: you can either customize your platform to generate advanced reports internally, or connect an external business intelligence tool that will help you take full advantage of all the information at your disposal.

Being a digital brands allows you to use data to your advantage: by accessing information that is not always available to traditional brick-and-mortar retailers, you can make smarter decisions, which reduces your costs and helps you stay competitive. The paradox here is that **data ownership is even more important for smaller brands, which don’t have access to economies of scale and can afford fewer mistakes.**

## Time to market

Because most SaaS solutions provide all the tools you need to start an online business out of the box, it will always be quicker to get your brand started with a SaaS platform than with an open-source framework, at least for a basic store. **If you’re in a hurry to get started and cannot afford to wait, you should definitely look into SaaS.**

With that said, one aspect to keep in consideration is the velocity of your team when evolving your store in response to market conditions. **In the hands of a skilled engineering team, an eCommerce framework will be not only quicker to adapt, but because it’s built to be customized, it will also allow you to make optimizations that stand the test of time.** SaaS platforms, on the other hand, often require ugly hacks that cost you more time in ongoing maintenance than for their initial development.

For most brands, time to market for the initial launch is not a relevant factor. On the other hand, time to market in capitalizing new opportunities and evolving your eCommerce experience can make or break a digital brand.

## So… which one is it?

As you have seen, there are different factors to take into consideration when choosing the best eCommerce platform for your needs. Most of them boil down to two key aspects: experience and vision.

**If you are only getting started in eCommerce, or think of your brand mainly as a product company, you should probably consider SaaS options.** They will make selling online a no-brainer, at the cost of technical limitations and a higher total cost of ownership.

**If you are an eCommerce veteran, or consider customer experience to be paramount in building your brand, you should instead going with an open-source framework**, making a larger upfront investment in order to have a flexible platform that will allow you to deliver a completely custom experience.

The Nebulab