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

Andrew Vathanakamsang

If you're running NetSuite as your ERP and Shopify as your storefront, you've probably encountered Celigo. Maybe you're new to the team and you've spotted "integrator.io" in the Shopify apps. You're wondering: how exactly does this sync orders, inventory, and customer data between our systems?

For some brands, Celigo is infrastructure that just works. For others, it's a annual expense that creates as many problems as it solves. The difference comes down to understanding what Celigo actually does, what it costs beyond the sticker price, and whether your operation genuinely needs it.

Here's how to make that call.

## What Celigo Actually Does

Celigo is an integration platform as a service (iPaaS) designed to move data between applications without writing custom code. Think of it as centralized plumbing for your tech stack—instead of building separate integrations between Shopify and NetSuite, Shopify and Klaviyo, NetSuite and your warehouse management system, you manage all those connections in one place.

The platform works through **flows**—automated processes that move data from a source endpoint to a destination endpoint. A flow might listen for new orders in Shopify via webhook, transform that data into the format NetSuite expects, and create a sales order record. Another flow might sync product data from NetSuite to Shopify every hour, ensuring your website inventory stays current.

Celigo provides several tools to build these flows:

- **Pre-built connectors** for popular applications (particularly strong for NetSuite + Shopify)
- **Visual mapping tools** to transform data from one schema to another
- **Filters and branching** to route data based on conditions
- **Lookup functions** to enrich data from additional sources
- **JavaScript hooks** for custom logic when visual tools aren't sufficient
- **Error handling and monitoring** with audit logs and alerting

The interface resembles Shopify Flow—visual, configuration-driven, accessible to non-developers. The difference is scale and sophistication. While Shopify Flow handles simple automation within the Shopify ecosystem, Celigo manages complex, bi-directional data flows across enterprise systems.

## The NetSuite Advantage

Celigo's strongest use case is NetSuite integration. The company has deep ties to NetSuite (their offices are reportedly close to each other), and their marketplace includes pre-built integration bundles for NetSuite + Shopify that handle common scenarios out of the box: order sync, inventory sync, customer sync, and fulfillment updates.

These pre-built integrations are both Celigo's biggest strength and a potential limitation.

On the strength side: they work well for standard use cases, getting you operational quickly without custom development. A typical flow might sync product data managed in NetSuite to your Shopify storefront, or push new Shopify orders into NetSuite for fulfillment. The integration handles the heavy lifting—API authentication, rate limiting, data transformation, error handling—without requiring deep technical expertise. And Celigo maintains these integrations as APIs change, which means you're not scrambling to fix broken integrations every time Shopify or NetSuite releases an update.

On the limitation side: these pre-built integrations are black boxes. You install an app, configure settings, and trust that the underlying logic works correctly. You don't have full transparency into how data flows or how edge cases are handled. When you need customization beyond what the pre-built integration supports—and most brands eventually do—you're layering custom code on top of an abstraction you don't fully control.

For brands running standard NetSuite + Shopify operations, this trade-off often makes sense. The pre-built integration handles 80% of requirements immediately, and you can customize the remaining 20% as needed. For brands with complex, highly customized workflows where the integration itself is a competitive advantage, the black box becomes a constraint.

## The Real Costs Beyond the Price Tag

Celigo's pricing is a function of the number of endpoints (applications you connect) and flows. Connect Shopify, NetSuite, Klaviyo, a CRM, and a marketplace, and you're looking at multiples of that base price.

Beyond licensing costs, there's operational overhead that doesn't appear on the invoice but directly impacts whether Celigo delivers value:

- **Ownership and expertise.** Despite marketing that positions Celigo as a no-code solution for business users, complex integrations still require technical expertise. You need someone who understands API rate limits, data transformation, error handling, and the quirks of each connected system. That person needs to read documentation, debug cryptic error messages, and make architectural decisions about data flow. The visual UI makes simple things easier, but it doesn't eliminate the need for technical competence. You're not avoiding development work—you're doing development work in a different interface.
- **Testing limitations.** Unlike custom code with unit tests and CI/CD pipelines, testing Celigo flows is primarily manual. You can use sandbox environments and clone flows for testing, but you're essentially testing in production. When you embed JavaScript hooks within flows—a common pattern as integrations grow more complex—that code typically isn't covered by automated tests. For teams accustomed to test-driven development and code review processes, this feels like a step backward. The ease of making changes in a visual interface means changes happen without the rigor you'd apply to custom code.
- **Change management and sprawl.** The ease of building flows is a double-edged sword. When anyone can create a new flow to solve a problem, flows multiply without oversight. Someone builds a new flow, the old flow gets turned off but never deleted, and six months later nobody remembers why either exists. Without discipline around documentation, review, and cleanup, Celigo becomes a sprawl of undocumented integrations that's harder to maintain than well-structured custom code. And because you're charged per connection, unused flows that remain active are literally costing you money for nothing.
- **Vendor lock-in.** The more flows you build in Celigo, the more committed you become to the platform. Migration costs grow with every integration. This isn't unique to Celigo—it's true of any iPaaS—but it's worth considering upfront. You're not just buying a tool; you're committing to an ecosystem. If Celigo's pricing changes, if the platform doesn't scale with your needs, or if you need capabilities Celigo can't provide, extracting yourself becomes expensive and time-consuming.

## When Celigo Is the Right Choice

Despite these considerations, Celigo is the right choice for many e-commerce brands. You'll know you're a good fit if:

- **You're using NetSuite.** If your ERP is NetSuite and you need to sync data with Shopify, Celigo's pre-built integrations are hard to beat. The alternative is building and maintaining custom NetSuite integrations, which is expensive and time-consuming. NetSuite's API is powerful but complex, and keeping integrations current as both platforms evolve requires ongoing development effort. Unless you have highly specialized requirements that the pre-built bundle can't accommodate, Celigo will get you operational faster and cheaper than custom development.
- **You have multiple integration points.** The value of a centralized integration platform grows with the number of connections. If you're syncing data between Shopify, NetSuite, Klaviyo, a CRM, multiple marketplaces, and a warehouse management system, consolidating those integrations in one place provides real operational value. Monitoring, error handling, and maintenance all happen in one interface instead of scattered across multiple systems. When an integration fails, you have one place to check. When you need to understand how data flows through your stack, you have one source of truth.
- **You have budget and dedicated ownership.** Celigo isn't a casual purchase, but for brands doing $50M+ in revenue where integration failures directly impact operations, the cost is justifiable. Equally important: you need someone to own the platform. This doesn't have to be a full-time role, but it needs to be someone's responsibility to maintain flows, review changes, monitor errors, optimize connections, and audit what's actually being used. Without ownership, Celigo becomes expensive shelfware that creates more problems than it solves.
- **Pre-built connectors exist for your stack.** Celigo's marketplace includes over 700 application connectors. If the vendors in your tech stack are well-represented—particularly if you're using popular e-commerce tools like Klaviyo, NetSuite, various marketplaces, and common CRMs—you benefit from pre-built integrations that Celigo maintains. If you're connecting to niche systems or building everything with universal HTTP connectors, you're doing custom development anyway. At that point, the value proposition diminishes significantly.

## When Custom Integration Makes More Sense

Conversely, Celigo is probably the wrong choice if your requirements, team structure, or workflows don't align with what the platform does best:

- **Your integration needs are simple.** If you're only syncing data between two or three systems with straightforward requirements, custom integrations or lighter-weight tools may be more cost-effective and easier to maintain. Paying for infrastructure you could build and maintain with a few hundred lines of code doesn't make economic sense.
- **You have strong in-house development capability.** Teams comfortable building and maintaining API integrations, implementing queue-based job systems, and writing comprehensive tests may find custom integrations more flexible and easier to reason about than visual flows with embedded JavaScript. If your engineering culture prioritizes code quality, test coverage, and version control, Celigo's visual interface and limited testing capabilities will feel like a constraint rather than an enabler.
- **Your workflows are highly customized.** Pre-built integrations work best for standard use cases. If your business processes are differentiated and complex—if the way you handle orders, inventory, or customer data is a competitive advantage—you'll end up customizing so heavily that you're essentially building custom integrations within Celigo's framework. At that point, the framework becomes overhead rather than value. You're paying for abstraction that gets in your way.
- **Testing and code quality are non-negotiable.** If your engineering culture requires comprehensive test coverage, code review, and version control for all business logic, Celigo's primarily manual testing approach and visual interface won't meet your standards. The JavaScript hooks you embed in flows aren't easily testable. Changes to flow configuration don't go through pull requests. You're trading control and rigor for convenience, and that trade-off may not be acceptable.

## Making Celigo Work For You

If you decide Celigo is right for your operation, success depends on treating it like critical infrastructure rather than a set-it-and-forget-it tool. Apply the same rigor you'd use for custom code:

- **Establish ownership.** Assign someone—whether an internal team member or an external partner—to own the platform. This person reviews all changes, maintains documentation, monitors errors, and ensures flows follow consistent patterns. Without ownership, Celigo becomes a free-for-all where flows proliferate without oversight.
- **Implement change management.** Don't let the visual interface create a culture where anyone can modify production flows without review. Require review before flows go live, maintain documentation for each integration, and create regular backups using Celigo's snapshot feature. Treat flow changes like code commits—document what changed, why it changed, and what the expected impact is.
- **Audit regularly.** Review active connections quarterly. Disable flows that aren't being used. Delete deprecated integrations. Connection count drives cost—keeping unused connections active is literally paying for infrastructure you don't need. We've worked with brands running 40+ active flows where only 12 were actually necessary. The rest were duplicates, abandoned experiments, or workarounds that outlived the problems they solved. Each represented both technical debt and unnecessary licensing costs. Regular audits prevent this waste.
- **Plan for testing.** Accept that testing will be more manual than with custom code. Use sandbox environments where possible, clone flows for testing changes, and maintain detailed runbooks for validating integrations after updates. When you embed JavaScript in flows, test that code in isolation before deploying it. Recognize that you're essentially testing in production, and plan your deployment process accordingly.
- **Monitor proactively.** Configure alerts for critical flows. Review error logs regularly. Integration failures are often silent—data stops syncing but no one notices until inventory is wrong or orders are missing. Proactive monitoring catches issues before they impact operations. Set up notifications for flow failures on mission-critical integrations like order sync or inventory updates.

## Making the Build-vs-Buy Decision

The build-versus-buy decision for integrations isn't primarily technical—it's strategic. Celigo works best when your competitive advantage lies elsewhere. If data synchronization is necessary infrastructure but not a differentiator, buying a platform lets you focus resources on what actually distinguishes your brand in the market.

But if your integration requirements are unique, if your workflows are a competitive advantage, or if you have the capability to build and maintain custom integrations efficiently, Celigo may add complexity without commensurate value.

The wrong answer is choosing based on what seems easiest in the moment or because NetSuite + Shopify brands just use Celigo. The right answer requires understanding your actual requirements, your team's capabilities, your budget constraints, and your long-term technical strategy.

Trying to decide whether Celigo's annual fixed cost and ongoing maintenance cost makes sense for your operation? Dealing with flow sprawl in an existing implementation? Or evaluating whether custom integration would serve you better? We help e-commerce brands make this evaluation based on their actual requirements, team capabilities, and strategic priorities. [Let's talk!](https://nebulab.com/contact-us)


Before You Buy: What Shopify Brands Need to Know About Celigo

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

*This is the second article in a series about enterprise e-commerce replatforms. The first article is about [running discovery workshops](https://nebulab.com/blog/replatform-discovery-workshops), which lay the foundation for a successful migration strategy.*

Replatforming is one of the riskiest moves an enterprise e-commerce team can make. For brands processing thousands of orders an hour, the thought of switching platforms conjures visions of downtime, lost sales, and panicked operators scrambling to fix errors. It’s no surprise that many CTOs and e-commerce managers hesitate to move to Shopify Plus, even when their legacy platform is holding them back.

But it doesn’t have to be that way. At Nebulab, we’ve developed a phased, risk-mitigated approach to Shopify replatforming that allows enterprise brands to make the switch incrementally—without downtime, feature freezes, or disruptions to daily operations. The key? A zero-risk rollout strategy that begins with a comprehensive Discovery Workshop.

## How to Roll Out Shopify Without Risk

One important tradeoff to consider with this approach: while it may slightly increase the overall project timeline, it significantly shortens your time-to-value. Because you're launching a lean implementation early in the process, your team begins learning, iterating, and delivering value from day one—long before a traditional big-bang launch would go live.

Our rollout strategy begins by identifying a part of the business that can be safely isolated. This might be a low-volume country, a non-core sales channel, or a product line with minimal business impact. We then build a lean Shopify implementation for that segment, prioritizing reliability over feature parity.

Once live, we run both platforms in parallel. To maintain data consistency, we implement bi-directional sync mechanisms between Shopify and the legacy platform. Orders, inventory updates, and customer data are pushed in near real-time via middleware or a shared OMS. For instance, when an order is placed on Shopify, it is instantly mirrored on the legacy platform, and vice versa. This ensures fulfillment, accounting, and analytics teams can continue operating without change.

Depending on the systems involved, we may use webhooks, direct API integrations, or tools like Matrixify—especially when data is already formatted for its use. Where necessary, we normalize data structures across platforms to avoid inconsistencies and edge-case failures. The result is a seamless flow of information, so business teams don’t need to alter their workflows.

We also implement robust monitoring and logging for every sync operation. This allows us to detect and resolve any data mismatches or delays before they become operational problems. By this stage, Shopify is already live in production—but the real value lies in observing its performance with real traffic and users.

Let’s break down the phases of a hypothetical rollout plan:

## Phase 1: Run Shopify Side-by-Side

In the first phase, we establish a dual-platform setup.

![](https://cdn.sanity.io/images/kqgmf0g2/production/61212d99d708984bdd92ed04f5614daa3bf15178-2572x1408.png?fit=clip)

Here’s how it works:

* We launch Shopify for a single, low-risk market or sales channel. This might be a small international market or a limited product line.
* Users in that segment interact solely with Shopify, while other markets continue using the legacy platform. A useful trick here: leveraging Shopify’s new Customer Accounts. These accounts use one-time passwords, so we can migrate only the relevant users’ orders without needing password data. Later, we can connect accounts with a custom [identity provider](https://help.shopify.com/en/manual/customers/customer-accounts/new-customer-accounts/identity-provider) if needed.
* Shopify and the legacy platform are tightly integrated. Products and collections sync from the legacy platform to Shopify, preserving PIM processes. Orders placed on Shopify sync back to the legacy system or a shared OMS, so downstream integrations and operations (fulfillment, finance, support) remain unchanged.

This setup lets us test Shopify in a real-world environment without disrupting existing operations. If needed, rollback is simple: we redirect traffic back to the legacy platform without affecting back-office systems.

## Phase 2: Scale Up, One Market at a Time

The second phase is about expanding Shopify’s footprint through multiple, incremental iterations.

![](https://cdn.sanity.io/images/kqgmf0g2/production/ad05fda4084d4ded3afcb43eab002a0db60c5252-2558x1442.png?fit=clip)

We do this by:

* Selecting the next market or sales channel with lower business impact.
* Identifying gaps between current Shopify features and that market’s requirements—such as shipping methods, currencies, or languages.
* Filling those gaps to prepare Shopify for increased traffic.

For example, we might help a brand expand from a single EU market to several, simply by iterating on localization and shipping options. As each iteration proves successful, we redirect traffic and repeat the process, steadily building confidence.

Eventually, all segments are running on Shopify—a sign that the migration is functionally complete.

## Phase 3: Shut Down the Legacy Stack

Now that all traffic has moved to Shopify, we begin dismantling the old platform.

![](https://cdn.sanity.io/images/kqgmf0g2/production/e2a91030b561cf780cfba72648c210221d07946f-1874x1438.png?fit=clip)

This phase is essential for reducing technical overhead and cost. Rather than replacing all integrations at once, we decouple each one individually, each with its own rollback plan. This reduces the risk of introducing widespread issues.

A typical sequence might start with analytics, followed by CRM and other integrations. Each step gives us a chance to verify behavior and performance before moving on to the next.

By the end, every integration runs directly through Shopify, and we can fully decommission the legacy system with confidence.

## What This Looks Like in the Real World

With a parallel architecture in place, we expand Shopify’s role country by country, channel by channel. Each new launch is reversible. If issues arise—UX bugs or operational hiccups—we simply reroute traffic to the old system.

In one recent project, we started with a few low-impact countries. The initial Shopify build handled basic operations but deliberately omitted full feature parity. This allowed rapid testing and iteration. As each market validated the setup, we introduced localized features and content. Eventually, the platforms became so similar that migrating the core markets felt like a natural final step.

Another client, using a headless setup, took a slightly different route. They began by migrating their image CDN—a feature included in any Shopify plan. This alone offset the cost of their plan. Next, they moved PDPs to Shopify’s Storefront APIs. PLPs are next, still powered by Algolia, which remains synced with the old platform. Bit by bit, they’re building a safer, modular migration path.

## When Is a Phased Rollout Worth It?

This phased, dual-system approach is ideal for large, complex e-commerce operations. A full cutover is too risky: even a single hour of downtime can cost tens of thousands and cause long-term brand damage. With deep integration needs across ERPs, OMSs, CRMs, and analytics platforms, maintaining operational continuity is non-negotiable.

Running both platforms in parallel creates a safety net that justifies the extra engineering effort.

One important tradeoff to consider: while this approach may slightly extend the overall project timeline, it significantly shortens your time-to-value. Because you're launching a lean implementation early, your team starts learning, iterating, and delivering value much sooner than with a traditional big-bang launch.

Smaller brands may not need this level of complexity. If your tech stack is simpler, with fewer integrations and lower order volume, a direct switch might be more efficient. At Nebulab, we help clients choose the right strategy based on their scale, risk tolerance, and operational maturity.

## Replatforming Without Regret

Traditional replatforming aims for full feature parity before launch. That usually leads to long timelines, bloated requirements, and fragile go-lives that can’t be reversed.

Our approach is different. We start small, test early, and scale with intention. With robust data sync, meticulous planning, and real-world validation, we make each phase of migration safe, reversible, and rooted in operational reality.

Enterprise replatforming doesn’t have to be an all-or-nothing gamble. With the right strategy, you can migrate to Shopify Plus in a safe, phased, and fully reversible way. [Let's do it together!](https://nebulab.com/contact-us)

A Dual-Run Strategy for Zero-Downtime Shopify Replatforms

As executives at enterprise and mid-market brands increasingly turn to more modern commerce platforms for their flexibility and ecosystem advantages, the stakes have never been higher. A failed replatform doesn't just mean cost overruns—it means lost revenue, damaged team morale, and potentially catastrophic business disruption.

The solution isn't more sophisticated technology or larger budgets. It's a disciplined approach to discovery that surfaces what truly matters before a single line of code is written.

## Why Most Agencies Get Discovery Wrong (And Why That's Expensive)

Here's the uncomfortable truth: most agencies treat discovery as a checkbox exercise. They'll send a brief questionnaire, schedule a few calls, and call it done. The reason is simple—*thorough discovery doesn't scale*. It requires senior talent, takes weeks to execute properly, and can't be easily templated across clients.

But this shortcuts approach creates predictable problems:

- **Misaligned stakeholders** discover fundamental disagreements three sprints into development.
- **Hidden technical debt** surfaces when legacy systems refuse to integrate cleanly.
- **Scope creep** becomes inevitable when requirements weren't properly captured upfront.

The financial impact is severe. We've seen brands burn through millions (yes, really) in development costs before realizing their initial assumptions were wrong. One client came to us after three failed projects in which different agencies had attempted to migrate the brand's custom subscription model to Shopify—failures that could have been prevented with a proper discovery process.

## The Executive Case for Deep Discovery

Consider discovery an insurance policy for your replatforming investment. A properly executed discovery workshop costs 5-10% of your total project budget but can prevent 50-80% of the risk factors that typically derail implementations:

- **Risk mitigation** is the primary value proposition. Discovery workshops identify integration challenges, stakeholder misalignments, and technical constraints before they become expensive problems.
- **Accelerated time-to-market** follows naturally. Teams aligned on clear requirements move faster than teams constantly having to change course.
- **Improved team dynamics** emerge from collaborative planning. Discovery workshops reveal communication patterns, decision-making processes, and internal politics that will impact your project's success.

## Nebulab's Discovery Framework: A Five-Phase Approach

Our discovery process has evolved through countless replatforming projects over the years. It's designed to surface critical information and design an implementation plan that minimizes risk and maximizes alignment.

### Phase 1: Stakeholder Alignment and Baseline Setting

Before any workshop begins, we identify the right participants. This isn't about including everyone—it's about including the *right* people. We need at least one representative from each department that will either execute the replatform or be impacted by its results.

**The stakeholder selection process matters more than most teams realize.** Include too few people, and you'll miss critical requirements. Include too many, and the workshop becomes unwieldy. We typically aim for 6-8 participants maximum.

Each stakeholder receives a comprehensive questionnaire covering their role, current systems, performance metrics, and concerns. The survey is tailored to uncover the specific information we'll need for productive workshop discussions.

The questionnaire serves two purposes: it gives us baseline context and starts stakeholders thinking strategically about the project. When people arrive at the workshop, they're already mentally prepared for deeper discussions.

### Phase 2: Envisioning Success and Failure

Every workshop begins with alignment on what we discovered during stakeholder interviews. We present our findings and ask: "Does this accurately reflect your situation?"

**If everyone agrees, we proceed. If there's disagreement, we've identified a critical issue.** Internal misalignment often masquerades as technical complexity. Better to surface and resolve these conflicts in week one than discover them in month six.

Our first collaborative exercise involves **envisioning success.** Each stakeholder writes down what their ideal end state looks like—not just technical specifications, but business outcomes. Fast-forward to six months post-launch: what does success look like for your specific role and responsibilities?

**The counterpoint exercise, a Pre-Mortem, follows immediately:** if everything goes horribly wrong, why did it fail? This approach consistently surfaces risks that wouldn't emerge through traditional requirements gathering.

These exercises reveal stakeholder priorities and potential conflicts. When the marketing director envisions "flexible campaign landing pages" but the IT director fears "maintaining custom functionality," we know there's a conversation to be had.

### Phase 3: Architectural and User Journey Mapping

**Understanding your current state is prerequisite to designing your future state.** We map your existing technical architecture, focusing on data flow and system integration. We answer questions such as:

- What are the third-party systems you integrate with?
- How do inventory updates flow between those systems?
- What happens when a customer initiates a return?

We then conduct a user journey mapping exercise, **giving equal dignity to both customers and internal users.** Your operations team, customer service representatives, and marketing coordinators all have their own user journeys, with their own points of friction that impact business performance. A replatform that optimizes for end-customer experience while creating (or failing to address!) friction for internal users is a failed replatform.

The architectural and journey mapping exercises run in parallel, with insights from one informing the other. Technical limitations often explain customer experience friction, while user behavior patterns reveal why certain integrations are critical or what integrations are missing that would facilitate the user's life.

### Phase 4: Solutioning

In the fourth part of the workshop, we move into solutioning, where we design the new reality.

**In doing this, we typically aim to be very conservative with the consumer's user journey:** unless there's compelling business justification for dramatic change, the post-replatform consumer UX should closely mirror the existing one. This might seem counterintuitive: after all, isn't the whole point of the replatform to _improve_ the user experience?

While the answer is yes, that doesn't mean you should do it immediately. Postponing the UX improvements reduces development complexity, contains implementation costs, and minimizes the risk of alienating your users with a completely new UX. We've discussed this (somewhat counterintuitive) approach at length in [our article about replatforms:](https://nebulab.com/blog/ecommerce-replatforms) **time and time again, we've seen a more conservative approach outperform big-bang replatforms.**

Architectural changes, however, can and should be more transformative: during this phase, we redesign your e-commerce infrastructure to support your business objectives and enable future evolution. This means dropping legacy tools, improving how you use them, or adopting new ones, with the two-fold goal of streaminling your internal operations and enabling future evolution for your consumer UX.

### Phase 5: Launch Strategy and Risk Mitigation

In the fifth and final stage, we have a good understanding of where you are and where you want to be. All that's left to figure out is how to get there.

To do that, we design your launch strategy, and we do it **based on your scale and risk tolerance.** While smaller brands might opt for a coordinated launch across all channels and markets, enterprise clients typically require phased rollouts, beta testing with select customer segments, or market-by-market deployment.

The launch strategy is usually a mix of business considerations (e.g., will team members have to operate two systems until we're fully switched over?) and technical considerations (e.g., how are we going to keep data in sync between different systems during the interregnum?).

We also go deep on risk mitigation: what can go wrong at different stages of the project, how are we going to minimize that risk, and what is our recovery process for the worst-case scenario?

This phase concludes the workshop and produces your implementation roadmap, complete with timeline, resource requirements, and risk mitigation strategies.

## What Discovery Workshops Do (And What They Don't)

As you have seen, discovery workshops have several benefits:

- **They set the stage for a successful replatform.** Clear requirements, aligned stakeholders, and realistic timelines create conditions for successful partnerships, preventing friction and second-guessing.
- **They generate returns that extend far beyond replatforming projects.** The architectural diagrams, user journey maps, and stakeholder alignment achieved during discovery become valuable assets for future initiatives.
- **They improve your internal communication and decision-making processes.** The skills and frameworks learned during discovery transfer to other strategic projects.

However, a discovery workshop is not a panacea! No matter how thorough your workshop, you will never be able to capture your full spectrum of requirements, and you will still be left with unanswered questions. That's alright: the purpose of the workshop is not to eliminate uncertainty, but rather to identify the areas of biggest uncertainty so that you can adress them head-on during the project rather than pretend they don't exist.

If you're looking to replatform and could use some help running a discovery workshop, [reach out!](https://nebulab.com/contact-us) We've run countless workshops over the years and would love to help make your replatforming project a success.


Better E-Commerce Replatforms Require Better Discovery Workshops

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

When building custom applications for your Shopify store, one of the most consequential architectural decisions you'll make is how your app will interact with Shopify's data.

There are two primary approaches, each with distinct advantages and tradeoffs that can significantly impact your development process, maintenance overhead, and application performance:

1. **Database Sync Approach**: Maintain a synchronized copy of Shopify entities in your application's database, creating a local representation that your code can work with.
2. **API-First Approach**: Make direct API calls to Shopify whenever data is needed, avoiding local storage and working with the freshest possible data.

Having implemented both approaches across a number of enterprise Shopify integrations, I've seen firsthand how this seemingly technical decision can have far-reaching business implications.

Let's explore both models in depth!

## The Database Sync Model: Your Own Data Kingdom

The database sync approach creates a mirror of relevant Shopify data within your application's database.

This typically involves initial data import during setup, webhook subscriptions to capture real-time updates, background jobs to periodically reconcile and verify data integrity, and ORM-style data access in your application code.

In essence, you're creating a localized representation of the Shopify world that your application can efficiently query and manipulate.

### The Business Case for Database Sync

This approach shines in several key scenarios that leverage the power of local data access and relationship modeling:

* For data-intensive applications that need to perform complex operations across multiple Shopify entities, having local database access can dramatically improve response times.
* The ability to model relationships between Shopify entities in your own database allows for more sophisticated data handling. This becomes invaluable when your business logic depends on understanding connections that aren't directly exposed via Shopify's API.
* Shopify's API primarily focuses on current state, but many business decisions require historical context. By maintaining your own data store, you can preserve change history and implement point-in-time analysis.

In other words, whenever you need full ownership over your data, a database sync is the recommended approach.

### The Challenges of Database Sync

Despite these advantages, this approach comes with significant considerations that must be managed throughout your application's lifecycle:

* Your synced data is only as current as your last update. While webhooks provide real-time notifications for many events, there are edge cases where changes might not be captured immediately. This can lead to situations where you need to refresh objects before using them, as they might have been updated in Shopify but not yet reflected in your local copy.
* Maintaining a reliable sync mechanism requires ongoing attention to webhook management and error handling, rate limits during bulk operations, recovery mechanisms for missed updates, and schema evolution as Shopify's API changes. A home goods retailer experienced this challenge when Shopify updated their metafield architecture, requiring significant rework of their sync implementation.
* Building a robust sync framework adds complexity to your initial development effort. This includes modeling Shopify entities in your database schema, implementing reconciliation logic, managing webhook subscriptions, and handling edge cases and conflict resolution.

To mitigate these challenges, it's imperative to:

* Implement comprehensive webhook coverage to capture all relevant data changes.
* Develop reconciliation processes to catch missed updates and ensure data integrity over time.
* Consider write-through caching for critical updates that need immediate reflection in both systems.
* Include data freshness metadata on synced entities to help identify stale data, and implement circuit breakers to fall back to API when sync issues occur.

## The API-First Approach: Always Fresh, Always Direct

The API-first approach maintains minimal local state and relies on direct Shopify API calls whenever data is needed.

This approach features no comprehensive data mirroring, direct GraphQL or REST API calls for read operations, webhooks for triggering specific business logic, strategic caching for performance optimization, and more procedural code patterns for data access.

### The Business Case for API-First

This lighter-weight approach offers compelling advantages in scenarios where simplicity and up-to-the-moment data accuracy are paramount:

* By removing the complexity of data synchronization, you can focus development efforts on core business logic. This often leads to faster time-to-market and reduced maintenance overhead.
* For applications where decisions must be made on the absolute latest data—such as inventory allocation or pricing—the API-first approach eliminates any risk of working with stale information.

If your application treats Shopify as the definitive source of truth and doesn't need to extend its data model significantly, the API-first approach aligns perfectly with this philosophy, keeping your architecture simpler and more focused.

### The Challenges of API-First

The direct approach isn't without its own set of considerations that can impact application performance and development complexity:

* Shopify enforces rate limits on API requests, which can become restrictive for data-intensive operations. Without careful design, applications can hit these limits during peak usage.
* Working directly with Shopify's API means accepting its query patterns and limitations. Complex filtering, sorting, or relationship traversal that would be trivial in a local database might require multiple API calls or be impossible to perform efficiently.
* Without an ORM-style data layer, code often becomes more procedural and tightly coupled to Shopify's API structure. This can reduce code readability and make maintenance more challenging over time.

To mitigate these challenges, we strongly recommend that you:

* Design for efficient API usage patterns to minimize request volume and avoid rate limiting.
* Implement strategic caching for frequently-accessed data to improve performance without sacrificing freshness where it matters.
* Use GraphQL to minimize request volume by retrieving exactly the data you need.
* Build resilience for API unavailability through fallback mechanisms, and monitor rate limit consumption proactively to avoid disruptions.

## The Hybrid Approach: Best of Both Worlds?

Increasingly, sophisticated Shopify applications are adopting hybrid architectures that combine elements of both approaches to maximize advantages while minimizing drawbacks.

This balanced strategy might include syncing frequently-accessed reference data with long refresh cycles, maintaining critical calculated values locally, directly querying time-sensitive operational data, and using event-driven architectures to update local state selectively.

It's a pattern we've been experiment with lately with good results—stay tuned for future updates!

## Making the Strategic Choice: A Decision Framework

Rather than presenting this as a binary choice, consider these five key factors that should influence your architectural decision:

1. **Data Volume and Complexity**: The more Shopify entities you need to work with simultaneously, and the more complex their relationships, the more compelling the database sync approach becomes. High-volume data processing with complex relationships typically favors the database sync model.
2. **Real-Time Requirements**: If your application's core functionality depends on split-second current data (inventory, pricing for checkout), the API-first approach eliminates sync latency risks and ensures you're always working with the most current information.
3. **Development Resources**: The API-first approach typically has a lower initial development hurdle, though it may become more complex over time as caching and optimization needs grow. Teams with limited resources might start with API-first and evolve as needed.
4. **Business Continuity**: A local data store provides resilience against Shopify API outages or rate limiting, allowing core functionality to continue even during connectivity issues. Applications with high uptime requirements often benefit from the database sync approach.
5. **Analytics Requirements**: Applications with significant reporting and analysis needs benefit tremendously from local database query capabilities, making the database sync model particularly valuable for business intelligence applications.

## Align Your Technical Architecture with Your Business Strategy

The choice between database sync and API-first approaches isn't merely technical—it directly impacts your ability to deliver on core business requirements. By understanding the tradeoffs and aligning your architecture with your specific needs, you can build Shopify custom applications that provide lasting business value.

The most successful implementations I've seen share one common factor: they began with a clear understanding of the business requirements and let those drive the technical approach, not the other way around. Whether you're building your first Shopify custom app or evolving your existing architecture, taking the time to make this fundamental decision thoughtfully will pay dividends throughout your application's lifecycle.

Need expert guidance on your Shopify integration strategy? Reach out to schedule a consultation! Our team specializes in building high-performance custom apps and would love to help.

Designing Your Shopify App’s Data Architecture: A Primer

Michela Frecchiami

In e-commerce, a smooth and intuitive shopping experience can make all the difference—helping customers find what they need faster, increasing the chances they'll complete a purchase, and increasing their basket size.

While Shopify offers several features to enhance product presentation and purchasing flows, many merchants struggle with how to effectively display related products—such as variations, complementary items, and customizable sets—while keeping the their online store’s shopping experience intuitive.

In this article, we're going to showcase three different ways to present related products in a Shopify store and give you a clear framework for understanding what tool to use depending on your specific scenario.

Let's take a look!

## LAKE's Product Presentation Challenge: A Case Study

While working with premium sleepwear brand LAKE, we encountered multiple product presentation challenges that illustrated the importance of selecting the right tool for the job. LAKE's diverse product catalog—featuring style variations, complementary products, and customizable bundles—called for a deep understanding of product relationships before implementing technical solutions.

By analyzing how LAKE's products related to one another and how customers interacted with them, we were able to present an approach that addressed their specific business objectives. Specifically, LAKE wanted to explore different business scenarios:

* Enhance the product browsing experience by showing style variations (like sleeve length) on product pages.
* Implement more effective product recommendations using straightforward solutions.
* Create a customizable experience for bundled items that were being treated as single products.

After a thorough analysis of their customer journey, we discovered that no single Shopify app would address all these needs. Instead, we explored a hybrid approach based on the different types of product relationships.

## Three Solutions for Product Cross-Selling

Based on LAKE's needs and the different types of product relationships, we proposed three distinct solutions for cross-selling:

### 1. Combined Listings for Style Variations

For closely related style variations (like the same pajama top in short-sleeve and long-sleeve versions), we recommended Shopify Combined Listings. This feature (available exclusively on Shopify Plus and enterprise-level plans) allows merchants to display multiple related products as variants within a single listing while keeping them as separate products in the backend.

This means each product can have its own:

* Product title, product description, and metadata
* Unique image gallery
* Independent product URL for better SEO

Why it works for style variations:

* Customers can easily toggle between short-sleeve and long-sleeve options without leaving the page
* The variations are genuinely different versions of the same core product (same fabric, design, and general style)
* It provides a seamless browsing experience while keeping separate product URLs for better SEO and inventory management

<figure>
	<img src="https://cdn.sanity.io/images/kqgmf0g2/production/0e7ef79ee680f895fdcfa1e7762645e7c17c4ed7-1600x1052.jpg?fit=clip">
  <figcaption>A prototype for LAKE, showcasing a men's pajama set with two style variations.</figcaption>
</figure>

Another use case is using Combined Listings to display separates (i.e. top, bottom) that are often bought together.

<figure>
	<img src="https://cdn.sanity.io/images/kqgmf0g2/production/13771e641a9ab5940cc706364b59b131a59c4491-1600x1052.jpg?fit=clip">
  <figcaption>An example of how separates can be shown usinf Combined Listing.</figcaption>
</figure>


### 2. Quick Add to Cart for Complementary Products

One of the options LAKE asked us to explore was a flexible way to display matching products on the product page. For example, a women's pajama set and its matching version for children are perfect for a "mommy and me" moment. While these items are designed to complement each other, they are separate products targeting different users, not variations of the same item.

In this case, a Quick Add to Cart functionality works best:

* A women's pajama set and a child's pajama set are separate products rather than variations of the same core item, unlike short-sleeve and long-sleeve versions of a t-shirt
* A Quick Add button allows customers to add the matching children's set to their cart instantly, making it easier to purchase both and increasing the overall AOV
* Each pajama set retains its own product description, sizing chart, and imagery, ensuring clear product details and avoiding confusion

<figure>
	<img src="https://cdn.sanity.io/images/kqgmf0g2/production/ba256f0f864d3111809f4a6648b5e700e867cee6-1600x1052.jpg?fit=clip">
  <figcaption>Another prototype for LAKE, to explore the Quick Add to Cart solution.</figcaption>
</figure>

### 3. Bundling Apps for Customizable Sets

When customers need to personalize their purchases beyond what Combined Listings can offer, bundling apps from the Shopify App Store provide the necessary flexibility while still creating a cohesive shopping experience. These specialized apps excel in scenarios where:

* Customers need to select products in different sizes for related items (like tops and bottoms)
* Merchants want to offer mix-and-match sets with special bundle pricing as an upsell
* There's a need to maintain accurate inventory tracking for each item

For example, HoneyLove sells women's underwear, providing a sophisticated shopping experience that allows customers to select different sizes for tops and bottoms without navigating between product pages, streamlining the path to checkout.

<figure>
	<img src="https://cdn.sanity.io/images/kqgmf0g2/production/c31fe6803eda7868b77853a1f1dd8d8a0f523ea2-3200x2104.jpg?fit=clip">
  <figcaption>Honeylove showcases an activewear bundle with coordinated separates, allowing customers to mix and match pieces.</figcaption>
</figure>


## Implementing the Right UX for Your Cross-Selling Needs

As we've seen, these approaches aren't mutually exclusive—they can be combined strategically based on your specific business goals and product relationships.

To help streamline the decision between different cross-selling experiences, we suggest looking at your product relationships through two key dimensions:

* **Variation Complexity:** How different are the products? This ranges from simple variations like color and size to entirely separate but complementary products.
* **Purchase Intention:** How likely are customers to want these items together? This can range from items that are almost always purchased together to those that are only occasionally complementary.

By understanding where your products fall on these dimensions, you can choose the right tools to create an intuitive shopping experience that aligns with your business goals.

When you take time to analyze how your products relate to one another, you create shopping experiences that improve customer experience and increase transaction value, boosting sales and setting your brand apart from competitors.


Related Products in Shopify: Picking The Right Tool for the Job

Nick Belzer

If you're coming from a traditional e-commerce platform like Solidus or Magento, working with Shopify can feel like a significant adjustment. Unlike these open platforms where you can modify virtually any aspect of the codebase, Shopify operates more like a black box. You can't simply rewrite core functionality or directly access the underlying systems.

But that doesn't mean customization is impossible. Shopify has evolved to provide specific extension points where developers can inject custom functionality. These carefully designed interfaces allow you to expand Shopify's capabilities while maintaining the platform's stability and security.

Let's take a look at each one of them!

## 1. Theme Blocks: Customizing the Storefront Experience

When you install apps on your Shopify store, they can expose theme blocks that render within your storefront. This allows you to add new functionality to your theme without directly editing theme files.

Theme blocks come in two main types:

### Section Blocks

These render inside existing theme sections. If a section supports app blocks, you can include blocks exposed by your installed apps. The app defines the liquid template that gets rendered, the data being used, and the settings available.

For example, a ratings app might display a star rating block that shows both the average rating and individual reviews.

### Embedded Blocks

These are smaller UI elements that aren't specific to a section but appear throughout your site. Examples include helper tags, accessibility features, or customer service elements.

This approach is especially valuable when you don't have control over the theme but need to introduce visual elements. At Nebulab, we've used this for our Sprout app, creating visual elements in merchants' themes by exposing theme logic through app blocks.

For more details on implementing theme blocks, check out [Shopify's Theme Blocks documentation](https://shopify.dev/docs/storefronts/themes/architecture/blocks/theme-blocks/quick-start).

## 2. Web Pixels: Tracking Solutions for Checkout

Shopify is transitioning to a new checkout experience that will be fully controlled by the platform. By August 2025, all stores will be required to use this new system, which has significant implications for tracking and analytics.

The primary impact? **You'll no longer be able to add custom JavaScript to checkout and order status pages.** This limits your ability to track events using client-side tracking.

To address this limitation, Shopify has introduced web pixels - isolated containers that exist around tracking pixels:

### App Pixels

These are included with apps you install on your Shopify store. Examples include Instagram or TikTok pixels. Once installed and connected to your ad accounts, they automatically subscribe to relevant events and send data to their respective platforms.

Some, like TikTok, employ a hybrid approach:
- Client-side tracking through the app pixel
- Server-side enrichment by using the app's API credentials to fetch additional order information

### Custom Pixels

If you need to send data to a platform that doesn't offer an official Shopify app, you can create custom pixels. These allow you to:
1. Subscribe to specific events (like checkout completion)
2. Import the tracking platform's pixel 
3. Use their API to send the data provided by Shopify

This approach creates a unified tracking system across your theme and checkout pages, despite Shopify's checkout limitations.

Learn more about implementing web pixels in our blog post: [Web Pixels on Steroids: How To Enrich Your Shopify Analytics](https://nebulab.com/blog/shopify-web-pixels).

## 3. Shopify Flow: Merchant-Controlled Automation

Shopify Flow enables merchants to create their own automation workflows through a user-friendly interface. While Shopify provides many built-in triggers, conditions, and actions, the real power comes from custom extensions.

As developers, we can extend Flow by creating:

1. **Custom Triggers**: Events that initiate workflows (e.g., "subscription created" or "subscription renewed")
2. **Custom Actions**: Operations that can be performed (e.g., "pause subscription")

By exposing these elements to Shopify Flow, we empower merchants to build their own business logic without developer intervention. 

For example, a merchant might create a workflow where when a subscription containing a specific product is created, an email notification is sent to their fulfillment team. This creates powerful automation possibilities without custom development for each use case.

For more insights, read our post on [Building Custom Shopify Automations](https://nebulab.com/blog/custom-shopify-automations).

## 4. UI Extensions: Customizing Key Experiences

As Shopify takes more control over critical customer touchpoints like checkout and account pages, they're providing UI extensions to maintain customization possibilities. These extensions let you inject custom UI elements at specific points:

### Checkout UI Extensions

With Shopify's new checkout experience, you can add custom elements like:
- Product information displays
- Upsell opportunities
- Delivery information
- Custom fields

At Cometeer, we use checkout extensions to display virtual product information, helping customers understand what's in their cart, and to offer relevant upsells.

### Account Portal Extensions

As Shopify's new customer account experience gains adoption, UI extensions let you integrate custom functionality. For subscription businesses, this might include subscription management interfaces directly within the customer account.

Like admin UI extensions, these must use Shopify's component libraries and follow their design patterns.

For a hands-on guide, check out our tutorial on [How To Build Your First Shopify POS UI Extension](https://nebulab.com/blog/building-shopify-pos-extensions).

## 5. Admin UI Extensions: Enhancing the Shopify Admin

Admin UI extensions allow you to render UI elements at specific points within the existing Shopify admin. Unlike embedded apps, these extensions integrate directly into admin pages like orders, products, or customers.

For example, we implemented an extension at Cometeer that displays coffee mapping details directly on the order page:

- When a customer orders a virtual product (like a coffee box)
- The extension shows which specific coffees were selected
- It displays the scoring logic used to select those coffees
- Operators can see this context without leaving the order view

Admin UI extensions must use Shopify's component libraries, ensuring they maintain the admin's look and feel. This creates a seamless experience where your custom functionality feels like a native part of Shopify.

Learn more about implementing these in our post: [Into the Light: Bringing Visibility to Your Shopify Customizations](https://nebulab.com/blog/custom-shopify-uis).

## 6. Embedded Apps: Creating Admin Interfaces

Embedded apps provide the most flexible way to extend Shopify's admin interface. When a merchant installs your app, it appears in their admin navigation. Clicking on it renders an iframe containing your custom interface.

This approach gives you complete control over the UI and functionality, allowing you to build complex interfaces for managing custom data and workflows. For instance, a subscription app might use an embedded app to display:

- All active subscriptions
- Detailed subscription information
- Management controls (pause, cancel, etc.)

While you have freedom in what you render, using Shopify's Polaris component library creates a native-feeling experience that integrates seamlessly with the rest of the admin.

Embedded apps support multiple pages and navigation, making them ideal for complex workflows that require dedicated interfaces.

For a detailed guide on building embedded apps, see [Shopify's Embedded App documentation](https://shopify.dev/docs/apps/auth/oauth/getting-started).

## 7. Shopify Functions: Injecting Custom Logic

Shopify Functions represent the closest thing to the traditional plugin architecture found in open platforms. They allow you to inject custom code directly into Shopify's processing flow at specific extension points.

These functions receive inputs from Shopify, process them according to your logic, and return outputs that influence Shopify's behavior. Current extension points include:

- **Discount Functions**: Create custom discount types beyond what's available in the admin
- **Location Rules**: Control which fulfillment locations are chosen during checkout
- **Validation Rules**: Define when orders can proceed through checkout

Functions come with constraints:
- Limited execution time
- Restricted code size and resource usage
- Must be deterministic
- Written in Rust or JavaScript
- Hosted on Shopify's infrastructure

Despite these limitations, Functions enable powerful customizations. For example, a loyalty program might use a custom discount function to provide member-specific discounts on certain product combinations - something not possible with standard Shopify discounts.

For more information, refer to [Shopify's Functions documentation](https://shopify.dev/docs/api/functions).

## Conclusion: Choosing the Right Extension Approach

When extending Shopify, selecting the right approach depends on what you're trying to accomplish:

- **For visual customizations**: Theme blocks let you inject UI components into the storefront without theme modifications.
- **For tracking and analytics**: Web pixels provide a standardized way to capture checkout events despite Shopify's checkout restrictions.
- **For merchant-controlled workflows**: Shopify Flow extensions empower merchants to create their own business logic.
- **For checkout and account customization**: UI extensions maintain customization as Shopify standardizes these experiences.
- **For enhancing standard admin pages**: Admin UI extensions integrate directly into existing workflows.
- **For complex admin interfaces**: Embedded apps give you complete control over custom management interfaces.
- **For custom business logic**: Shopify Functions let you modify platform behavior at specific points.

The extension landscape continues to evolve as Shopify balances merchant customization needs with platform stability. Staying current with these options ensures you can deliver the custom experiences clients need while working within Shopify's constraints.

Remember that sometimes combining approaches yields the best results. For instance, an embedded app might manage configuration while Shopify Functions implement the actual logic.

If you need expert guidance on your Shopify integration strategy, [reach out!](https://nebulab.com/services/shopify) At Nebulab, we specialize in building high-performing Shopify store for midmarket and enterprise brands, and we'd love to help you build the e-commerce experience you need to shine.

The Complete Guide to Customizing Your Shopify Store in 2025

Andrea Vassallo

Ryan Woods

The subscription economy has become one of the most significant business transformations of the 21st century, reshaping industries from media and e-commerce to software and mobility. With projections estimating its market valuation to reach $3 trillion by 2025([1](https://blulogix.com/blog/the-2025-blueprint-for-scalable-growth-in-the-subscription-economy/), [2](https://recurly.com/blog/subscriptions-weekly-25-01-07/)), this shift is fueled by technological advancements, changing consumer expectations, and businesses prioritizing predictable revenue models.

For e-commerce executives, few technology decisions carry more strategic weight than choosing between building a custom subscription engine or purchasing a third-party solution. This choice affects not only your technology stack but also your operational flexibility, customer experience, and long-term profitability. Many successful e-commerce brands have recognized that off-the-shelf Shopify subscription solutions don't always align with their unique business needs, leading them to explore more tailored approaches.

## Buy vs. Build: Evaluating the Trade-Offs

At its core, the decision between purchasing a third-party subscription management platform and building a custom solution is a trade-off between convenience and control. While third-party solutions like Recharge provide a fast and accessible way to implement subscriptions, businesses that scale beyond a certain threshold often find themselves constrained by these platforms. Let's explore both paths through key considerations.

### Speed and Ease of Implementation

Third-party platforms like Recharge offer a plug-and-play solution, allowing businesses to quickly launch a subscription model with minimal technical overhead. These platforms handle the complexities of recurring billing, customer portals, and integration with existing e-commerce operations. For early-stage subscription businesses, this is a huge advantage, as it enables rapid market entry without a heavy upfront investment in technology.

However, the convenience of ready-made solutions comes with trade-offs. Most third-party systems are built to serve a broad range of businesses, which means they may not fully align with the specific needs of a rapidly growing or highly differentiated subscription business. While these platforms accelerate the initial setup, they can introduce rigid framework constraints that limit customization options in the long run.

### Flexibility and Customization

As subscription volumes grow, many businesses find that third-party platforms that initially accelerated their growth become limiting factors. The universal design that makes these platforms broadly applicable also makes them difficult to customize for specific business needs.

For instance, standard subscription platforms typically treat each subscription as a separate contract, resulting in multiple shipments and shipping charges for customers with multiple subscriptions. Businesses with complex product offerings often need to create subscription bundles and personalized delivery schedules that aren't supported by off-the-shelf platforms. This lack of flexibility is one of the main reasons why high-growth businesses start considering custom solutions.

A custom-built subscription engine, on the other hand, provides complete control over the customer experience. Companies can build flexible delivery frequency options, pattern-matching algorithms for product recommendations, and seamless pause/resume functionality that enhance customer loyalty. These become strategic differentiators that would be difficult or impossible to achieve within the confines of a third-party system.

### Strategic Control and Business Sovereignty

When relying on a third-party subscription platform, your business is dependent on the vendor's development priorities and strategic decisions. If the platform discontinues features, raises prices, or pivots its business model, your subscription business must adapt accordingly. This lack of control can be a significant risk, especially when subscriptions are a core component of your revenue model.

Building a custom solution eliminates this dependency. Developing an in-house subscription engine represents an investment in business sovereignty. It allows companies to dictate their own product roadmap, prioritize features based on customer needs, and innovate freely without waiting for a platform provider to release updates.

### Cost Considerations: Short-Term vs. Long-Term Economics

For businesses just entering the subscription space, third-party platforms provide a cost-effective entry point. Monthly fees are predictable, and there is no need for a large upfront investment in software development. However, as subscription revenue scales, the economics shift dramatically.

At scale, monthly platform fees for third-party solutions can reach $20,000 or more, directly impacting profit margins. These per-transaction or revenue-percentage fee structures become increasingly painful when business volumes spike. For businesses with tens of thousands of subscribers, the fee structure can threaten to consume an unsustainable portion of subscription profits.

By contrast, while custom development requires significant upfront investment, the total cost of ownership (TCO) often favors bespoke solutions beyond a three-year horizon. For enterprises with over $50M in annual recurring revenue, custom builds typically achieve 22-35% TCO savings over a five-year period, assuming in-house DevOps capabilities.([3](https://www.ishir.com/blog/110513/build-vs-buy-software-analysis-which-is-right-for-your-business-in-2024.htm)). Most businesses determine that the crossover point where building becomes more economical than buying occurs approximately 48 months after launch, with increasing savings thereafter.

### Integration and Data Control

Third-party platforms often create data silos and integration challenges with existing business systems. This can limit the ability to build seamless connections with inventory management, customer service platforms, and marketing automation tools. Without deep integration, businesses must rely on workarounds or manual processes, which can introduce inefficiencies and errors.

A custom-built subscription engine allows for full integration with a company's existing tech stack. Growing brands need to maintain real-time connectivity with their customer experience stack—support platforms, SMS marketing tools, and email communication systems, among others. A custom implementation preserves these connections, ensuring seamless data flow and minimizing disruption for both employees and customers.

### Competitive Differentiation and Innovation

When subscription functionality is merely a transactional feature of your business, third-party platforms provide adequate solutions. However, when the subscription experience is a fundamental aspect of your brand differentiation, a custom-built solution can create a long-term competitive advantage.

For many direct-to-consumer brands, subscriptions aren't just a revenue model; they're central to the brand experience. By building a custom solution, companies can implement sophisticated algorithms that analyze customer preferences and purchase history to optimize renewal timing, suggest complementary products, and create truly individualized subscription experiences. These innovations help increase retention rates and customer lifetime value—outcomes that would be difficult to achieve with an off-the-shelf platform.

## Case Study: MeUndies' Subscription Transformation

MeUndies, a leading direct-to-consumer underwear brand, provides an illuminating example of successfully navigating the build vs. buy decision for subscription technology.

The company initially found that their custom subscription system was not well-aligned with off-the-shelf Shopify subscription solutions. As their subscriber base grew into the tens of thousands, the limitations of third-party platforms became increasingly apparent.

For MeUndies, several factors drove their decision to build a custom solution:

* **Unique product bundling needs**: They needed to create subscription bundles and personalized delivery schedules that weren't supported by standard platforms.

* **Brand differentiation through experience**: Subscriptions weren't just a revenue stream but central to their brand identity. Their custom solution implemented pattern-matching algorithms for product recommendations and flexible pause/resume functionality that significantly enhanced customer loyalty.

* **Integration requirements**: MeUndies needed seamless connectivity with their tech stack, including Kustomer for support, Attentive for SMS marketing, and Iterable for email communications.

* **Economic considerations**: The company determined that their build vs. buy crossover point would occur at approximately 48 months post-launch, after which their custom solution would provide increasing cost advantages.

The results validated their decision. MeUndies' custom subscription engine delivered flexible delivery frequency options and personalized experiences that increased retention rates and customer lifetime value—achievements that would have been challenging to implement using a third-party platform.

## Making the Transition: Key Considerations

If your business is approaching the tipping point where custom development makes sense, consider these critical factors:

* **Development Resource Planning** – Building in-house requires dedicated engineering teams with subscription commerce expertise. Alternatively, partnering with an experienced development agency like Nebulab can streamline production, mitigate risks, and prevent costly mistakes.

* **Migration Strategy** – Transitioning from a third-party platform to a custom solution requires careful planning. A phased migration approach—starting with small customer cohorts—helps validate functionality before a full transition.

* **Future-Proofing Architecture** – A custom solution should be designed with scalability in mind. Planning for future growth, maintenance, and integrations ensures that the platform remains cost-effective over time.

* **Data Strategy** – Subscription businesses thrive on data. A custom solution should prioritize data collection, accessibility, and actionability to drive strategic insights and operational efficiency.

## When to Build: Making the Right Investment for Your Business

Building a custom subscription engine delivers strategic advantages that off-the-shelf solutions simply cannot match. While it requires an initial investment, a tailored solution provides long-term benefits that go beyond cost savings, offering complete control over customer experience, operational workflows, and business innovation.

Before choosing the build route, assess your subscription volume, growth trajectory, and unique business requirements. Custom solutions deliver maximum ROI for businesses with >$50M ARR and specialized operational needs—particularly those where subscription experiences represent a core competitive differentiator.

Is your business hitting the ceiling with third-party platforms? Are transaction fees eating into your margins? Could subscription innovation drive competitive advantage in your market? If so, it's time to explore building your own subscription engine to secure your place in the rapidly growing subscription economy.

Partnering with an experienced team—such as Nebulab—can significantly reduce development costs by streamlining the process, mitigating risks, and preventing costly mistakes. A knowledgeable partner ensures that scalability, maintenance, and integrations are planned from the outset, minimizing total cost of ownership (TCO) over time. The result is a tailored, flexible solution that grows with your business rather than forcing you to conform to the limitations of a generic off-the-shelf platform.

Should You Build or Buy Your Shopify Subscriptions App?

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

In our work with e-commerce brands, we frequently encounter a common challenge: how do you build trust in systems that operate invisibly? While custom algorithms and automation solutions may be working flawlessly behind the scenes, both business teams and customer service representatives often struggle to confidently explain these processes to stakeholders and customers.

This scenario plays out repeatedly across e-commerce operations. While custom solutions deliver tremendous value, their invisible nature creates four critical challenges:

* Reduced trust in automated systems
* Limited opportunities for cross-team collaboration
* Increased support resolution times
* More difficult iterative improvements

The good news? We've developed several approaches to solve these visibility challenges, each suited to different business needs and constraints.

Let's explore each approach, starting with the quickest to implement and moving toward more comprehensive solutions. We'll share real implementation experiences and help you understand which solution might work best for your specific situation.

## 1. Tags

The simplest place to start is with Shopify's built-in tagging system. These lightweight markers can provide immediate visibility into system states and trigger automated processes. The beauty of tags lies in their simplicity – they're provided out of the box on Shopify and integrate seamlessly with existing workflows.

At Tannico, one of Italy's leading wine retailers, we use tags to control their product synchronization with their enterprise resource planning system. When products need to be synced, the operations team can simply add a specific tag, and our middleware picks up these tagged products for processing. This gives the team direct control over the sync process without needing to understand the underlying technical complexities.

## 2. Metafields

As your needs grow more sophisticated, metafields offer structured data storage capabilities that go beyond simple flags.

Again looking at our work with Tannico, we use metafields to store and control parameters for their third-party pricing engine. This allows the team to fine-tune pricing rules and see their effects directly within Shopify, making complex pricing management feel like a native part of their workflow.

While metafields require more planning and development effort than tags, they provide much richer data visibility without adding significant complexity to operations. They're particularly valuable when you need to store detailed configuration data or track complex states that can't be captured with simple tags.

## 3. Admin UI Extensions

When simple flags and data storage aren't enough, Admin UI Extensions offer a more sophisticated approach. These extensions allow you to create custom interfaces directly within the Shopify Admin, making complex operations more intuitive and accessible to your team.

[Our work with Cometeer](https://nebulab.com/case-studies/cometeer) serves as a perfect example of this approach. Their algorithm was making sophisticated decisions about which coffees to include in each box, considering factors like customer preferences, previous orders, and inventory availability. However, without visibility into this process, it was difficult for teams to understand and trust these selections.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a6b7f0a08d0748f778e20893e2dbb0a5373d226f-1386x1050.png?fit=clip)

We transformed this "black box" system into a transparent one through a comprehensive Admin UI extension that visualizes the entire decision-making process. The results were remarkable: customer service representatives could now explain algorithm selection decisions, the time required for algorithm adjustments dropped as developers could now see exactly how their changes affected the selection process and, perhaps most importantly, non-technical team members began contributing valuable suggestions for improvements.

While this approach requires more initial investment in development time and resources than tags or metafields, it offers the most flexibility for complex interactions and rich data presentation.

## 4. Third-Party Platforms

As systems grow more complex, teams often need more sophisticated ways to interact with custom logic. While the previous solutions work well within Shopify's Admin interface, sometimes the best approach is to meet your teams where they already work by integrating with their daily platforms.

Many customer service and operations platforms like Zendesk and [Kustomer](https://developer.kustomer.com/kustomer-apps-platform/docs/widgets) provide robust API integration capabilities. This means you can surface key data from your custom Shopify solutions directly within these platforms and, more importantly, enable actions to be taken from there.

![](https://cdn.sanity.io/images/kqgmf0g2/production/15f920216eff929c332ecf67a9c340c42f28cd27-956x1168.png?fit=clip)

At [MeUndies](https://nebulab.com/case-studies/meundies), we integrated their custom subscription logic directly with their customer service platform. This meant that when handling customer inquiries, support teams could see relevant subscription data (like upcoming shipment dates and product preferences) and perform actions like skipping deliveries or updating preferences—all without leaving their familiar support interface. The integration eliminated constant switching between tools and made customer interactions more efficient.

The complexity of this approach varies based on the platform you're integrating with. Data exposure typically involves formatting and forwarding information through authenticated API requests. Enabling actions requires more setup as you'll need to create secure endpoints in your middleware to handle authenticated requests from the third-party platform. While this requires careful planning and ongoing maintenance, it can significantly streamline workflows for teams that spend most of their day in these platforms.

## 5. Custom Frontends

While the previous approaches cover most use cases we encounter, there are times when you need complete control over the user experience. In these situations, creating a custom frontend offers the ultimate in flexibility. Shopify provides robust support for embedding custom applications directly into the Admin Panel through their embedded app framework, with dedicated libraries for both Remix and Rails to handle the complexities of setup and authentication.

This approach gives you complete control over the user interface and functionality, allowing you to create exactly the experience your team needs. While we haven't found this level of customization necessary for most clients at Nebulab – the other solutions typically provide sufficient flexibility – it's worth considering for unique use cases that require specialized interfaces or workflows.

![](https://cdn.sanity.io/images/kqgmf0g2/production/53bfe0a056a980d2d3bc89539ca562d0f4993be7-2880x1620.png?fit=clip)

Development platforms like [Retool](https://retool.com), [Replit](https://replit.com) and [Gadget](https://nebulab.com/blog/building-shopify-apps-with-gadget) can significantly accelerate this process. Retool's drag-and-drop interface builder and pre-built components can reduce frontend development time by 50-70%, while Replit's collaborative development environment streamlines the iteration process. These platforms handle much of the foundational setup work, letting your team focus on building the unique features your business needs.

The trade-off here is still higher development effort and maintenance complexity compared to other solutions we've discussed, even with these acceleration tools. However, for organizations with highly specific needs or unique operational requirements, the investment can pay off through perfectly tailored workflows and improved team efficiency.

## Choosing Your Path

The best visibility solution for your organization depends on your specific needs and constraints. Here's a quick decision guide:

* **Tags**: Best for simple status tracking and quick wins with minimal investment
* **Metafields**: Ideal for structured data storage and analysis platform integration
* **Admin UI Extensions**: Perfect for complex interactions and rich visualizations
* **Third-Party Integration**: Choose when teams primarily work in other platforms
* **Custom Frontends**: Best for highly specialized needs requiring complete control

**Our experience has taught us that successful implementations start small and scale up based on actual usage patterns.** Begin by identifying which processes are currently invisible and causing pain points for your teams. Then start with simple solutions that address these immediate needs, gather feedback from users, and iterate based on real-world usage. Document everything thoroughly and train your teams effectively – visibility tools are only valuable if people know how to use them.

**You'll know your implementation is successful when you see**:

* Customer service resolution times decreasing
* Internal teams expressing greater confidence in automated systems
* Cross-team collaboration increasing
* System maintenance time and error rates improving

**These metrics consistently improve with better visibility into custom solutions.**

Ready to explore how these visibility solutions might work for your specific needs? [Contact our team](https://nebulab.com/contact-us) for a consultation. We'd love to help you bring your custom solutions into the light.

Into the Light: Bringing Visibility to Your Shopify Customizations

The Shopify ecosystem features a plethora of services and frameworks designed to help developers launch their own apps, whether they’re custom apps only meant to be installed on a specific store or public apps that will be listed on the Shopify app store.

Among these tools is [Gadget](https://gadget.dev/), claiming to be “the fastest way to build and run web apps.”

Gadget wants to be your one-stop shop for all of your full stack app development needs by providing a platform to handle all of the infrastructure needed to build and deploy an app.

At its core, it offers a managed PostgreSQL database and auto-generates an API package, complete with TypeScript support and React client integration. Developers can write server-side JavaScript code that runs on a serverless Node.js platform powered by Fastify, while the frontend development is simplified with a pre-configured React scaffold powered by Vite.

![](https://cdn.sanity.io/images/kqgmf0g2/production/ccc1ec82bad8e5a6f57c4d51528ddd41b1a9278a-2856x2172.png?fit=clip)

Gadget apps are always live from the moment they are created, and development environments can be promoted to production with a couple of clicks. On top of this, it offers an Integrated Development Environment (IDE) to manage both code and data in a unified location.

While Gadget is now a tool for building any sort of Web app, it was originally born to accelerate the development of Shopify apps. The Shopify integration provided by Gadget streamlines a lot of boilerplate work by offering:

- Data models for all your Shopify objects that you can augment with new attributes, stored on Shopify as custom metafields.
- Webhook subscriptions for object creation, update and deletion.
- So-called **actions** which allow you to run custom logic to keep Gadget in sync with your Shopify instance.

Gadget also publishes a TypeScript API that you can use to manage your custom data models. As an added bonus, this package is then made available through a registry, so it can be integrated in your Shopify storefront or any other JavaScript application.

Today, we’re going to take Gadget for a spin by using it to build a simple custom app that records the history of price changes for our Shopify products.

## Building Our Sample Gadget App

When creating a new app, we suggest starting with an  **Empty React embedded app**. Gadget also offers some pre-built app templates, but these don’t always work out of the box unfotunately, making for a subpar development experience.

Our Gadget app will need to read **productVariant** objects, as that’s where Shopify stores the variant price, so we need to select the **Product variant** scope when creating the app:

![](https://cdn.sanity.io/images/kqgmf0g2/production/50696d4cc9fd8601284264d42b53520aeae783ed-2910x2160.png?fit=clip)

At this point, can install the app in our Shopify store. To do this, we need to:

1. Create a Shopify app from the Shopify Partner Portal.
2. Copy the Shopify app’s Client ID (the app identifier) and Client Secret and plug them into Gadget’s configuration panel for our Gadget app.
3. Copy the URLs generated by Gadget and paste them in our Shopify app’s configuration panel. 
4. Go back to the Shopify app overview and select a store where we want to install the app.
5. Grant our app the required permissions in the dialog that pops up.

If all went well, we should now be able to see the default Gadget app UI in our Shopify store’s admin panel.

### Syncing Data Between Gadget and Shopify

To experience a bit of Gadget’s magic, we can check the **Installs** tab in the Gadget sidebar and start a **Sync** for the store we just installed our app in. This will sync our Gadget database with our Shopify store.

![](https://cdn.sanity.io/images/kqgmf0g2/production/4d65fe5ba7b9900c0d9944b25cff6d13aa58793f-2480x518.png?fit=clip)

To explore our data, we can head over to the **shopifyProduct** model and check out its data view. 

The **data** view is one of the highlights of Gadget: without Gadget, we’d have to make GraphQL API calls to be able to see the data. Being able to quickly see our Shopify data in a tabular form feels like magic.

![](https://cdn.sanity.io/images/kqgmf0g2/production/c00c913b45be8117514f0aa5fe3574c989eb79ab-3034x2244.png?fit=clip)

Furthermore, Gadget automatically creates webhook subscriptions for every accessible Shopify model, and by default, reacts to every change in the Shopify stores by ingesting changes: object creations, updates deletions are synced in near-real-time with Gadget’s database. If we attempt to edit a product, we should be able to see the changes shortly thereafter in the corresponding data view.

### Extending Our Gadget App with Custom Functionality

The simple app we're building just needs to record the history of prices set for our products. To do that, we need to store this data *somewhere*.

One way to do this would be to add a metafield to our variants. However, reading and writing the metafield would still requires going through the good old Shopify GraphQL queries and mutations, which requires a lot of boilerplate code. This is an annoying limitation of Gadget’s operating model.

Instead, let’s create a new **priceChange** model via the sidebar. Given we don't need to run calculations or any fancy analyses, we can structure the price field as a string, just as it is presented in the **productVariant** model.

We also want to correctly model the relationship between the **productVariant** model and the **priceChange** model: each **productVariant** should have multiple **priceChange** records. Setting this up via the Gadget UI is a breeze and very intuitive:

![](https://cdn.sanity.io/images/kqgmf0g2/production/1a30f13a82c332cfb7d06c17b3a903ad6af445cd-3034x1710.png?fit=clip)

Finally, we need to actually create a **priceChange** record on every price change. In order to do that, we can edit the **update** action for the **shopifyProductVariant** model, which governs what happens when variants are updated:

```jsx
// api/models/shopifyProductVariant/actions/update.js

export async function onSuccess({ params, record, logger, api, connections }) {
  const newPrice = params.shopifyProductVariant.price;

  if (newPrice != api.shopifyProductVariant.findOne(record.id).price) {
    api.priceChange.create({ newPrice, shopifyProductVariant: { _link: params.shopifyProductVariant.id } });
  }
};

```

With all of this in place, we can then test it by editing a product price on our store and then heading to the **priceChange** data view to verify the new addition:

![](https://cdn.sanity.io/images/kqgmf0g2/production/3fc38fe79407ae829db1952d8485118b7cb1cf73-2470x612.png?fit=clip)

### Taking It Further

Consuming the API built on the Gadget backend from any JavaScript or TypeScript application is as easy as installing an NPM package hosted directly in the Gadget registry, or including a minified script in your already existing web application. The API is kept in sync and documented automatically for you by the Gadget platform, which makes it a breeze to work with.

This would allow us, for instance, to read the record of price changes in our Shopify theme in order to show them to the customer (something that may be useful for compliance with the European Omnibus directive).

## Is Gadget Right For Your Shopify Customizations?

The answer is “it depends.”

If your team is already familiar with Gadget’s underlying technologies and ecosystem, picking up Gadget and feeling the magic of the robust webhook management and data synchronization  is a huge productivity boost, greatly reducing time-to-market for the applications you’ll be building.

However, if your Shopify application needs to deploy a checkout extension, a Shopify Function, or some other feature that’s not directly integrated in the app codebase, you can’t just use the Gadget UI. Instead, you’ll need to clone the code locally via the `ggt` command line tool, and then rely on the Shopify CLI to complete these tasks. While this adds some friction, it also allows you to use your preferred tools to work on the codebase, and `ggt` will still keep your data models in bi-directional sync between Gadget and your codebase.

Developers evaluating Gadget should also be mindful of platform lock-in: the platform takes over pretty much your entire custom app infrastructure, forcing you to play by their technical and commercial rules. If you ever need to migrate off of Gadget, the price to pay may be significant.

In conclusion, for teams prioritizing rapid Shopify app development over platform independence, Gadget offers a compelling and solid foundation to build upon. If, on the other hand, you value owning your infrastructure and want full control over your development environment, you’re probably better off developing your app from scratch.

A Primer to Building Custom Shopify Apps with Gadget

Gift-giving is an art, and when it comes to online shopping, the canvas can sometimes feel cluttered. For DTC brands, the opportunity to make this experience memorable is now more within reach than ever, especially as the global personalized gifts market—valued at USD 51.98 billion in 2024—is expected to grow to [USD 138.17 billion by 2030](https://www.marketresearchfuture.com/reports/personalized-gifts-market-10348). 

This demand for customization and gifting underscores the importance of adding thoughtful touches like personalized messages, gift wrapping, and unique packaging to create an exceptional and seamless gifting experience.

Many DTC brands with smaller catalogs rely on external platforms to offer ready-to-use gifting solutions, like sending e-cards instead of physical products or allowing recipients to provide their shipping information—creating a convenient, customizable experience similar to gift cards. 

However, this reliance on third-party platforms can result in a fragmented user experience, akin to a ping-pong match between the store and the gifting service, which can introduce friction into the process.

Even with custom gift options available, most stores fail to deliver an engaging gifting experience. It's easy to treat gifting as an afterthought, but in reality, a shopper's gift-giving journey begins long before they add an item to their cart—often even before landing on a product page.

## DTC Brands and the Power of Unique Gifting Experiences

Unlike B2C e-commerce or marketplaces, DTC brands often offer unique, special products that attract gift-givers seeking a personalized touch. A well-crafted gifting experience not only sets these brands apart from their competitors but also enhances brand sentiment and serves as a powerful customer acquisition tool, similar to referral programs.

By addressing specific aspects such as tailored filters, cart and checkout optimizations, and personalized experiences for email subscribers, businesses can elevate their gifting offerings and engage both gift-givers and recipients more effectively.

Let's explore these key points to uncover valuable insights, tips, and best practices that can enhance the overall gifting experience.

### Streamlining the Gift Discovery Process

Shopping for someone else can be challenging, especially if users aren’t familiar with the recipient's preferences. This is particularly true in categories like toys, fashion, or beauty products, where age and trends heavily influence choices.

To make the gift-giving process smoother and more enjoyable, e-commerce sites should offer "Recipient" filters, such as Age or Gender. Mori, a brand specializing in kids' and babies' apparel and accessories, provides common gifting categories like "Newborn Baby Gift" along with recipient filters, demonstrating how these features can help customers refine their search based on the recipient's demographics and interests.

E-Commerce stores selling products frequently bought as gifts can significantly improve the gift selection process by following these insights:

* **Age and gender filters:** Allow users to narrow their search by offering filters based on the recipient's age, gender, or relationship (e.g., "For Her" or "For Kids").
* **Interest-based filters**: Let customers filter products based on hobbies, interests, or lifestyle categories, such as "For Pet Lovers" or "For Fitness Enthusiasts."
* **Occasion filters:** Offer filters for specific occasions like "Birthday," "Anniversary," or "Holiday Gifts" to help users choose based on the event.
* **Personalized recommendations:** Use customer data or popular trends to highlight products that suit common gifting scenarios, offering a personalized touch.
* **Filter placement:** Ensure filters are prominently placed, ideally in the main navigation menu or homepage, for easy access and a streamlined browsing experience.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/7a2437b926981d7723352af400450ea947a6a5e1-1600x1052.jpg?fit=clip" alt="Mori Baby Mori recipient filters">
  <figcaption>Mori Baby Mori offers a thoughtful and personalized gifting experience on their site, allowing customers to add gift wrapping, personal messages, and curated bundles that cater to new parents and babies.</figcaption>
</figure>

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/20910d0dd249e64b3fc92d7124dfe61a8065c6ce-1600x1052.jpg?fit=clip" alt="Maisonette recipient filters">
  <figcaption>Maisonette provides a curated gifting experience with options to select beautifully packaged gifts, customizable messages, and handpicked collections for children and parents, making it easy to find thoughtful presents.</figcaption>
</figure>

### Optimizing the Product Page for Gifting
Once users have found a potential gift, providing clear and accessible gifting options on the product page is crucial for a seamless purchasing experience. As the personalized gifts market is projected to grow at a compound annual growth rate [(CAGR) of 12.97%](https://www.marketresearchfuture.com/reports/personalized-gifts-market-10348), the demand for custom options like gift wrapping, messages, and unique packaging is increasing. By clearly displaying these options and offering transparency around costs, DTC brands can capture this growing segment and ensure a positive, memorable gifting experience for their customers.

Many e-commerce sites overlook this step, which can lead to frustration for gifter-givers who need to know early on what gift options are available without digging through the checkout process. Lake, for example, effectively advertises its branded gift box on the product page, offering an easy way to add it to the cart and providing detailed options, streamlining the gifting decision for users.

To optimize the product page for gifting, consider these strategies:

* **Display gifting options clearly**: Show available gifting options—such as gift wrapping, custom messages, or special packaging—on the product page to help users make informed decisions early.
* **Make gifting costs transparent**: Clearly state any additional costs associated with gift services like wrapping fees or packaging upgrades, preventing unpleasant surprises later in the process.
* **Link to more gifting information**: For complex gift services include a link to a dedicated gifting info page where users can explore options in detail, keeping the product page clean and focused.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/b114d6b08da9784a3ad53ef70a4235da221078ec-1600x1052.jpg?fit=clip" alt="Lake Pajamas offers Gift boxes in the buy section">
  <figcaption>Lake Pajamas offers a simple yet elegant gifting experience, allowing customers to add gift boxes, personalized messages, and luxurious packaging to their orders, perfect for presenting their high-quality sleepwear as thoughtful gifts.</figcaption>
</figure>

### Enabling Customers to Enter a Gift Message
A key feature for sites offering gifts is the ability to include a personalized message. While this seems straightforward, here are a few best practices:

* **Display Custom Message Option in the Cart:** Ensure the option to add a custom gift message is available and visible in the cart, so users can easily include it before completing their purchase.
* **Avoid prefilled gift messages:** Using preset messages like “I hope you enjoy this gift!” can confuse users, who might think the field is already filled in. Instead, only show a placeholder after users opt to include a message.
* **Use a "Save" button**: Rather than relying on autosave, provide a "Save" button so users feel confident their personalized message is securely stored.
* **Preview gift message in order summary:** Include a preview of the gift message in the order summary to reassure users that their message has been saved and will be sent with the order.


### Integrating Special Wrapping and Branded Gift Boxes into the Cart

Special wrapping or branded gift boxes can add a final, thoughtful touch to the gifting experience. Gifting features can vary widely across e-commerce sites, making it essential to provide clear information about these options. When incorporating special wrapping and branded gift boxes into the cart, consider the following insights:

* **Brief Descriptions:** Include short descriptions or icons representing gift wrapping and branded box options to help customers quickly understand the choices available.
* **Mark Free Options Clearly:** If gift wrapping or custom packaging is offered at no additional cost, clearly indicate that these options are free to prevent confusion.
* **Opt-Out Option:** Provide an easy way for customers to opt out of special gift wrapping or boxes if they prefer to skip these options.
* **Discounted Bundles:** Offer discounted bundles that include the product and gift wrapping or a branded box to increase the overall value of the purchase.
* **Delivery Times:** Especially during the holiday season, it's important to provide a delivery-date estimate or delivery-date range. Many stores that don't provide this information risk failing to deliver gift orders on time. By offering accurate delivery estimates, customers can plan their gift-giving effectively.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/75d41dc78e3e19448d4c7e313f9a31f966064129-1600x1052.jpg?fit=clip" alt="Lake Pajamas offers Gift boxes in the cart">
  <figcaption>The easy-to-spot "Select Gift Options" button ensures that customers can quickly personalize their gift, making the process of sending thoughtful, beautifully packaged sleepwear even smoother and more user-friendly.</figcaption>
</figure>


### Leveraging Personalization for Existing Customers
Offering personalized experiences for existing customers can elevate the gifting process and create a sense of connection between customers and your brand. Here are a few ways to achieve this:

* **Custom Profiles for Gift Recipients:** Allow customers to create profiles for their loved ones, where they can save important details such as birthdays, genders, sizes, and interests. This information can be used to prefill filters during the search process, making it easier and faster for customers to find the perfect gift.
* **Saved Items and Wishlists:** Enable customers to save their favorite items or create wishlists for each recipient profile. This not only simplifies the gift selection process but also encourages repeat visits and purchases.
* **Personalized Reminders and Recommendations:** Send your customers timely notifications before recipients' birthdays or special occasions, along with personalized gift recommendations based on the recipient's profile. This thoughtful gesture can increase customer satisfaction and foster brand loyalty.

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

Maisonette offers a great example of effective personalization features. Users with an account can save multiple profiles with details like name, date of birth, and gender. Maisonette then provides selections based on these data, and users receive a notification one month before the recipient's birthday with a special promotional code. Such personalization can lead to higher conversion rates, increased customer retention, and greater overall success in the competitive DTC market.

## Wrapping Up the Perfect Gifting Flow

The gifting experience is a crucial aspect of e-commerce, particularly for DTC brands specializing in unique, high-quality products. As shoppers increasingly seek personalized and memorable gifts, e-commerce sites must meet these expectations by offering thoughtful and transparent gifting options.

Remember that a well-executed gifting experience can be a powerful differentiator in the competitive e-commerce landscape, providing both immediate benefits and long-term gains for your brand. As you refine your gifting strategy, keep in mind the importance of creating a seamless and enjoyable shopping journey that fosters customer engagement and loyalty.

Ready to enhance your gifting experience? Get in touch with the team at Nebulab to create a seamless, personalized, and memorable gifting process that delights your customers and drives results. Whether it's optimizing product pages, integrating custom messages, or adding unique packaging, we can help you turn your DTC e-commerce into a go-to destination for thoughtful gifts. 

Together, we can make your gifting strategy truly stand out! [Reach out today.](https://nebulab.com/contact-us)

How DTC Brands Can Elevate Their Gifting Experience

The Shopify POS suite is a key component of Shopify’s Unified Commerce approach, enabling merchants to create rich omnichannel experiences that bridge their offline and online shopping channels. Initially launched in 2013, Shopify has continued to improve its POS hardware over the years, making it more powerful and expanding availability to [more countries.](https://www.shopify.com/editions/summer2024#pos-in-more-countries)

What sets Shopify’s POS lineup apart from the competition is the flexibility merchants have in designing their POS setup, with various [card readers](https://www.shopify.com/pos/store/collections/card-readers) for different environments and the ability to connect a [cash register](https://www.shopify.com/pos/store/collections/cash-drawers), [barcode scanner](https://www.shopify.com/pos/store/collections/barcode-scanners), and [receipt printer](https://www.shopify.com/pos/store/collections/receipt-printers-and-paper) optionally.

In terms of functionality, while Shopify’s POS system comes with [a rich set of native features](https://www.shopify.com/pos/features), Shopify also offers the ability to customize the POS system using Apps. The Shopify App Store already features [200+ POS apps](https://apps.shopify.com/app-groups/extensions/point-of-sale), offering product bundles, loyalty programs, and retail staff management features.

Still, if these apps don’t cater to your needs, you can develop your own POS UI extension—a trend becoming increasingly popular as Shopify starts serving larger merchants with more sophisticated requirements.

In this article, we will show how to do exactly that: by taking inspiration from a real-world scenario, we will build an end-to-end Shopify extension that allows your customers to show a QR code while completing in-store purchases to connect the purchase to their customer account. This eliminates the need for a store associate to look up the customer by their name or email and creates a nice “wow” moment for the customers.

Let’s get started!

## Creating Our Shopify App

Before we can get started building our extension, we will need the following:

* A working Shopify partner account
* The Shopify CLI running on our machine
* A development store with the [Checkout and Customer Accounts Extensibility developer preview](https://shopify.dev/docs/api/release-notes/developer-previews#checkout-and-customer-accounts-extensibility-developer-preview)

Once we have everything, the first step is to create a new Shopify App that will expose our custom functionality:

```
$ shopify app init
```

The CLI will ask what type of app we want to build. We need a Custom App since we’re building functionality specific to our store and not an app for general distribution.

Once we have our custom app, we must understand what [app surfaces](https://shopify.dev/docs/apps/build/app-surfaces) we want to hook into. In our case, we’ll need:

* A [Customer account UI extension](https://shopify.dev/docs/apps/build/customer-accounts) to show a customer their QR code in our online storefront.
* A [POS UI extension](https://shopify.dev/docs/apps/build/pos) that will allow store associates to scan the QR code to identify the customer.

Let’s start with the first one!

## Displaying the QR Code in the Storefront

Run the following command to create our Customer Account extension:

```
$ shopify app generate extension --name loyalty-card
```

When asked what type of extension to generate, select Customer account UI extension. The CLI will also ask whether we want to use JavaScript or TypeScript--we’re going with plain JavaScript for our example, but feel free to use whatever works best for you!

By default, the generator will create a `FullPageExtension.jsx` and a `MenuActionExtension.jsx` file as examples. We’ll want to remove them, along with their corresponding configuration in `shopify.extension.toml`, and replace them with a new extension:

```
# ...

[[extensions.targeting]]
module = "./src/LoyaltyExtension.jsx"
target = "customer-account.profile.block.render"

# ...
```

In `LoyaltyExtension.jsx`, we’ll write the code to render our QR code on the customer profile page. In this example, we’re generating the QR code with a free API, but we could use our own server (also, Shopify will support a [QRCode component](https://shopify.dev/docs/api/checkout-ui-extensions/unstable/components/other/qrcode) soon):

```
import { Heading, Text, View, BlockStack, Link, Card, Image, reactExtension, useApi } from '@shopify/ui-extensions-react/customer-account'

function LoyaltyExtension() {
  const { authenticatedAccount } = useApi()
  const customerId = `gid://shopify/Customer/${authenticatedAccount.customer.current.id}`

  return (
    <Card padding="small">
      <BlockStack spacing="tight">
        <Heading>
          Your Loyalty Card
        </Heading>
        <Text>
          Scan it in the store to earn points!
        </Text>
        <View maxInlineSize={128}>
          <Image source={`https://api.qrserver.com/v1/create-qr-code/?size=300x300&data=${customerId}`} />
        </View>
      </BlockStack>
    </Card>
  )
}

export default reactExtension(
  "customer-account.profile.block.render",
  () => <LoyaltyExtension />
)
```

While this looks like an ordinary React component, we won’t be able to import assets like images or use regular HTML tags. This is because Shopify renders the UI using its native engine. As a result, the styling of our extension is limited to the Components API and the brand styling inherited from the store.

With everything set up, we can test our extension by running:

```
$ shopify app dev
```

As part of this command, we must select a partner account and development store to test the app.

With the command running, we can preview our customer account UI extension by pressing P on our keyboard. The Developer Console will open up in our browser with a link to preview the extension. Clicking the link should show our QR code:

![](https://cdn.sanity.io/images/kqgmf0g2/production/300b8ad677bf19e7245ab3bac52ab4a91ac96284-1214x1390.png?fit=clip)

With the customer account UI extension working, we are halfway there. Customers can view their loyalty cards, but there is no way our staff can scan them just yet. Let’s see how to do that!

## Reading the QR code in the POS

To create an extension capable of scanning QR codes, we need to set up a POS UI extension that interacts with the barcode scanner and sets the customer on the current order when a customer QR code is detected.

Since this extension is part of the same feature we were working on earlier, we will generate the extension under our existing app:

```
$ shopify app generate extension --name loyalty-card-scanner
```

Even though POS extensions are set up similarly to customer account extensions, we need to do a bit more work. In the case of our POS extension, we need two components: 

* A tile that can be added to the home screen of the POS system.
* A modal that is opened when the tile is pressed.

(If you’re curious, you can find all possible targets for POS extensions [here](https://shopify.dev/docs/api/pos-ui-extensions/unstable/targets)).

Let’s start by creating the modal since we’ll need to use it in the tile. Create a file called `Modal.jsx` with the following contents:

```
import { Screen, Navigator, reactExtension, useScannerDataSubscription, CameraScanner, useApi } from '@shopify/ui-extensions-react/point-of-sale'

function Modal() {
  const { cart, toast, navigation } = useApi()
  const { data, source } = useScannerDataSubscription()

  // This runs on every change to `data`.
  if (data?.startsWith('gid://shopify/Customer/')) {
    const id = parseInt(data.split("/").pop())
    cart.setCustomer({ id: id })
    toast.show(`Found Customer: ${id}`)
    navigation.pop()
  }

  return (
    <Navigator>
      <Screen title="Scan Customer Loyalty Card">
        <CameraScanner />
      </Screen>
    </Navigator>
  )
}

export default reactExtension(
  "pos.home.modal.render", 
  () => <Modal />
)
```

Hopefully, the code is pretty self-explanatory:

1. We render a screen with a single `CameraScanner` component.
2. We use `useScannerDataSubscription` to listen for scanner data.
3. When our QR code is detected, we set the customer on the cart, show a toast, and close the modal.

Now that the modal is in place, we must implement a tile component allowing store operators to access it. This is quite straightforward! Just create a `Tile.jsx` file with the following contents:

Now that the modal is in place, we need to set up a grid tile to open it when clicked.   

```
import { Tile, reactExtension, useApi } from '@shopify/ui-extensions-react/point-of-sale'

const TileComponent = () => {
  const { action } = useApi()
  return (
    <Tile
      title="Add Customer"
      subtitle="Scan customer loyalty card"
      onPress={() => {
        action.presentModal()
      }}
      enabled
    />
  )
}

export default reactExtension(
  "pos.home.tile.render", 
  () => <TileComponent />
)
```

Tiles are interesting and offer much functionality out of the box; for instance, their API allows them to be dynamically enabled and disabled. You can learn more about them in [Shopify’s documentation](https://shopify.dev/docs/api/pos-ui-extensions/unstable/components/tile).

Now that we have our components, we must ensure our app knows where to render them. Add the following to `shopify.extension.toml`:

```
# ...

[[extensions.targeting]]
module = "./src/Tile.jsx"
target = "pos.home.tile.render"

[[extensions.targeting]]
module = "./src/Modal.jsx"
target = "pos.home.modal.render"

# ...
```

Unlike with customer account UI extensions, we cannot test POS UI extensions in the browser. Instead, we’ll need to download the POS app to a supported device, like a smartphone or tablet, that can scan QR codes.

Once we have the Shopify POS app on our device, we can run `shopify app dev`, press P, open the Developer Console, click on the “View Mobile” button, and scan the QR code with our mobile device. This will enable the developer preview for our extension on the device:

![](https://cdn.sanity.io/images/kqgmf0g2/production/2cf428d978c9b39006009b01c7d47aa865c16389-1874x342.png?fit=clip)

That’s it! Now that our custom app is fully working, it’s time to deploy it.

## Deploying the Custom App

Now that both extensions are defined and we are happy with the solution, we can deploy our app. By deploying the app, we make it available to the production stores under the same Partner account.

Since the app with our extensions satisfies [the requirements to be hosted by Shopify](https://shopify.dev/docs/apps/build/app-surfaces#hosting), all we need to do is run the following command:

```
$ shopify app deploy
```

Once the app is deployed, we can install it in our store through the Partner portal.

After installing the app, we need to add our grid tile to the POS home screen to our POS home screen and the Loyalty Card app block to our Account Profile page. Once the changes are published, our customers can find their loyalty card on their account page, and our associates can scan the QR codes via the POS.

## The Sky’s the Limit!

With just a few lines of code, we’ve leveraged Shopify’s customer account UI and POS UI extensions to create a smooth loyalty program experience for our most engaged customers. However, there’s so much more we could have done:

* We could retrieve and display a customer’s loyalty status and other data in the POS UI, helping store associates personalize the shopping experience.
* We could allow customers to add their QR code as an item to their Apple Wallet for an even easier (and cooler!) experience.
* We could apply dynamic discounts to the customer’s cart when they scan their QR code based on their shopping history or other parameters.

The only caveat is that we must stick to Shopify’s [APIs](https://shopify.dev/docs/api/pos-ui-extensions/2024-04/apis) and [UI components](https://shopify.dev/docs/api/pos-ui-extensions/2024-04/components) to achieve our goals. While this seems a limitation at first, it has some very appealing advantages: our POS UI extension, for instance, will work smoothly on *all* POS setups, from a single iPhone running the Shopify POS app to a fully-fledged setup POS Terminal setup with a tablet and external barcode scanner.

As Shopify adds more and more extension targets and capabilities to their APIs and UI components, brands will be able to achieve even more with even less--a badly needed superpower in today’s competitive consumer landscape. 

If you have a POS UI or other kind of UI customization in mind for your Shopify store and need help launching it, feel free to [reach out!](https://nebulab.com/contact-us) We’d love to help.

How To Build Your First Shopify POS UI Extension

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?

Daniel Bergholz

If you have used Shopify before, you’ve probably fallen in love with the Theme Editor. With its flexible content management options and smooth editing experience, this little piece of functionality is one of the reasons why brands love Shopify so much, and among the aspecs that make the platform so user-friendly compared to its competitors.

But if you decide to go headless, you might be appalled to find that the Theme Editor is not available on Hydrogen. In this case, you will need to either manage your content through code–a solution that dramatically slows down the pace at which you can make content changes–or implement your own content management solution.

In this article, we’ll show you how to do just that: by using Sanity, one of the most renowned and established headless content management solutions available today, we’ll give you quick walkthrough of how you can create a visual content management experience for your headless Hydrogen store.

Let’s dive in!

## Creating Our Content Schema

First of all, let’s create a new Hydrogen application:

```
$ npm create @shopify/hydrogen@latest
```

Now, sign into [Sanity](https://www.sanity.io) and create a new project. When asked how you want to set up your project, pick “From scratch with CLI”:

![](https://cdn.sanity.io/images/kqgmf0g2/production/6e5f37b582d5a25e0f14746437677f4f367331d5-1999x1165.png?fit=clip)

Your project and a public production dataset will be created. You will also receive instructions on setting up Sanity Studio for a JavaScript codebase.

![](https://cdn.sanity.io/images/kqgmf0g2/production/2a13ec2cd76a56f54e53e28442d682c9e82fb222-1999x1371.png?fit=clip)

Now, run the Sanity Studio setup command within the Hydrogen codebase, and name the resulting folder `studio`:

```
$ npm create sanity@latest -- --project [YOUR PROJECT ID] --dataset production --template clean
```

This should be the end result:

![](https://cdn.sanity.io/images/kqgmf0g2/production/3f411a4035a00219d829c4ce4387d89184246170-626x684.png?fit=clip)

All the files generated for Sanity Studio

Next, let's create a new document in Sanity to display later in Hydrogen. How about a promotional banner? Open `studio/schemaTypes/index.ts` and create the `banner` type:

```
import {defineField, defineType} from 'sanity'

const banner = defineType({
  name: 'banner',
  title: 'Banner',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      title: 'Title',
      type: 'string',
    }),
    defineField({
      name: 'content',
      title: 'Content',
      type: 'text',
    }),
  ],
})

export const schemaTypes = [banner]
```

Now run Sanity Studio locally, open [http://localhost:3333/](http://localhost:3333/), and create a few banners:

```
$ cd studio && npm run dev
```

![](https://cdn.sanity.io/images/kqgmf0g2/production/5038e128559f997b3b660faa780ac95a05aa43f4-1999x1234.png?fit=clip)

Et voilà, our content is available in Sanity! Now, it’s time to connect Hydrogen to Sanity, so that we can actually retrieve and display the content.

## Connecting Hydrogen to Sanity

We now need to connect our Hydrogen store to Sanity to retrieve this data and display it on the homepage. Let's install the official integration package in the root folder:

```
$ npm i hydrogen-sanity
```

Add a couple of environment variables to `.env`:
```
SANITY_STUDIO_PROJECT_ID=[YOUR PROJECT ID]
SANITY_STUDIO_DATASET=[YOUR DATASET NAME, USUALLY "production"]
SANITY_STUDIO_URL="http://localhost:3333"
```

Update the `server.ts` file from the root to include the Sanity Loader:

```
// ...all other imports
// Add imports for Sanity Loader and Preview Session
import {createSanityLoader} from 'hydrogen-sanity'

// Inside the default export
export default () => {
  // ... Leave all other functions like the storefront client as-is

  // (Prerequisite) If not already initialized, create a `withCache` handler...
  const withCache = createWithCache({cache, waitUntil, request})

  // 1. Configure the Sanity Loader and preview mode
  const sanity = createSanityLoader({
    withCache,
    client: {
      projectId: env.SANITY_PROJECT_ID,
      dataset: env.SANITY_DATASET,
      apiVersion: env.SANITY_API_VERSION || '2023-03-30',
      useCdn: process.env.NODE_ENV === 'production',
    },
  });

  // 2. Make Sanity available to all action and loader contexts
  const handleRequest = createRequestHandler({
    // ...other settings
    getLoadContext: () => ({
      // ...other providers
      withCache,
      sanity,
    }),
  })
}
```

Your Sanity client will now be available in `context.sanity` in all your Remix loaders!

## Retrieving Content from Sanity

Let’s try to visualize the banners we have created previously. 

Inside the homepage `app/routes/_index.tsx`, add a Sanity query to the loader function:

```
export async function loader({context}: LoaderFunctionArgs) {
  // ...other storefront queries

  const banners = await context.sanity.loadQuery(`*[_type == "banner"]`);

  return json({
    // ... storefront queries
    banners,
  });
}
```

And inside the same file, modify the UI to display the data we’re retrieving:

```
export default function Homepage() {
  const {banners} = useLoaderData<typeof loader>();

  return (
    <div className="banner-container">
      {banners.data.map((banner) => (
        <div key={banner._id} className="banner">
          <h2>{banner.title}</h2>
          <p>{banner.content}</p>
        </div>
      ))}
    </div>
  );
}
```

And here you go! We’ve added a bit of CSS to make the preview look nicer:

![](https://cdn.sanity.io/images/kqgmf0g2/production/9b20bed734c392865e89a5ec55bf3c2bf569c1a3-1534x416.png?fit=clip)

Obviously, this is a very basic example–in the real world, you’ll have a much richer content schema. You may even allow your content editors to compose pages however they want by creating a 1:1 mapping between your Sanity schemas to React components, adding live previews, etc.

The sky’s the limit, and we encourage you to check out [the Sanity documentation](https://www.sanity.io/docs) to learn about all the possibilities!

## Keep Up with The Ecosystem

In this article, we have rolled our custom Hydrogen-Sanity integration, but the Remix and Hydrogen ecosystem are evolving rapidly. In fact, Sanity used to offer ready-made templates for integrating with Hydrogen, but they’ve since been archived. Shopify also just announced that they will be [releasing their own visual editor very soon](https://hydrogen.shopify.dev/update/summer-editions-24-announcing-the-hydrogen-visual-editor-and-a-ton-of-dx-improvements), in which case it might be worth switching over!

All of this to say, make sure to stay on top of what’s happening in the ecosystem and follow the latest best practices if you don’t want to be left behind. And if you _do_ deviate from those best practices, make sure that you always have a good reason for doing it!

How To Integrate Your Shopify Hydrogen Store with Sanity CMS

So, you’ve reached the hard conclusion that [you need to build some middleware](https://nebulab.com/blog/ecommerce-middleware) for your Shopify store—perhaps you need to integrate with an exotic third-party system that doesn't offer a native app, or you have a complex subscription flow that cannot be accommodated by an off-the-shelf solution.

But once you've mapped out all the business requirements, you're still left with a million decisions to make: where should you host your middleware? What's the best architecture, a monolith or microservices? Should your code run on a fixed cadence or respond to Shopify's webhooks?

In this article, we're publishing some broad technical considerations we've collected over the years while working on middleware implementations for our clients. We suggest treating these as general guidelines: your mileage may vary depending on your requirements, team composition, and growth stage.

Let's dive in!

## Reactive vs. Scheduled Middleware

The first crucial architectural decision you'll make is whether your middleware should be reactive or scheduled.

Reactive middleware responds immediately to events triggered by external actions, such as customer purchases or inventory updates. It's the preferred choice when dealing with time-sensitive business logic, such as sending email notifications or updating order information.

In reactive middleware, incorporating a queue mechanism is imperative to facilitate the asynchronous processing of incoming event payloads. By decoupling the reception of webhooks from the actual processing logic, queues create a buffer that allows your middleware to absorb workload spikes seamlessly. They also mitigate the risk of data loss during processing disruptions, ensuring that all incoming events are reliably processed.

Queues are de facto mandatory when building middleware for Shopify, as your store will deactivate your webhook subscription [in case of multiple failures/timeouts.](https://shopify.dev/docs/apps/webhooks/best-practices#respond-quickly)

Additionally, you should design reactive middleware to be idempotent and resilient against race conditions, e.g., when handling duplicate or out-of-order event notifications. This allows brands to mitigate the risk of data corruption.

Scheduled middleware, on the other hand, operates on a predefined cadence, executing tasks at regular intervals. It's the preferred choice when dealing with bulk data operations, such as subscription processing or (in some cases) integrations with third-party systems.

Because scheduled middleware might process a substantial amount of data during each execution, optimizing performance and resource utilization is essential. This can be achieved by grouping data into manageable chunks and processing it in batches, minimizing resource contention and maximizing throughput. When integrating with third-party systems, it's also essential to be mindful of rate limits, maximum payload sizes, and the opportunity to leverage batch APIs whenever available.

By understanding the distinct functionalities of reactive and scheduled middleware, businesses can leverage these tools strategically to orchestrate complex workflows and optimize their Shopify operations for efficiency and scalability.

## Monoliths vs. Service-Oriented Architectures

Especially in larger projects, it's tempting to implement your middleware logic as a constellation of microservices, making up what's typically called a Service-Oriented Architecture, or SOA for short. Technically, these services may run as traditional long-lived web applications, but we often see them deployed in serverless environments such as AWS Lambda or Cloudflare Workers.

The theory is that this design increases technical freedom and reduces maintenance overhead: for instance, the subscription processing engine may be implemented using a technology different from the WMS integration. Plus, if they're deployed as serverless functions, there's no need to worry about scaling the services to match transaction volume because the infrastructure provider will handle that responsibility for us.

In our experience, however, most SOA setups suffer from premature optimization. The additional freedom and scalability come at the expense of a more complicated development and infrastructure setup, with multiple codebases to maintain and constraints on the deployment process. Code reuse is also more complicated, and rather than going through the hassle of building and maintaining an internal SDK, engineering teams often end up duplicating the shared code. In other words, the additional effort and complexity often outweigh the gains.

Because of this, when faced with complex middleware architectures, we always consider whether there's a chance to simplify things by moving to a [Majestic Monolith](https://signalvnoise.com/svn3/the-majestic-monolith/) deployed as a traditional, long-lived Web application. While they're not as fancy as a serverless SOA, monoliths have several advantages:

* Engineers only need to work in one codebase to make orthogonal changes, which makes it easier to work atomically.
* Code sharing across API endpoints and scheduled jobs is trivial since everything's in the same application.
* We only need to write and maintain a single deployment pipeline, which makes deployments simpler and more robust.
* We eliminate the need to deal with network failures, data model inconsistencies, and data synchronization issues.
* It's still easier and cheaper to find and onboard new engineers on a monolith vs. a SOA.

This is not to say that microservices and serverless architectures are always bad. There are situations where they can help with scalability, e.g., for trivial middleware that only needs to respond to a specific webhook (in which case a serverless infrastructure is acceptable) or when a particular piece of business logic can be optimized by rewriting it in a more suitable technology. However, these pros always need to balance against the additional complexity introduced into the system.


## Keep Your Options Open

As we mentioned at the beginning of this article, your mileage may and will vary, especially as time passes and your middleware starts taking on more responsibilities. Our suggestion is to regularly re-evaluate your design and architectural choices to ensure that your current setup is still the ideal fit for your needs.

Furthermore, remember that the best middleware is no middleware. Whenever you see an opportunity to simplify your architecture by removing custom logic in favor of a third-party solution, you should seriously evaluate it. E-commerce brands are not tech startups, and every dollar you save in development costs is a dollar you'll be able to invest in other areas of the business.

If you are struggling with fine-tuning your custom integrations or business logic, [don’t hesitate to reach out](https://nebulab.com/contact-us): we can help you navigate and streamline the complexity, finding the ideal setup for your brand.

Designing and Scaling High-Throughput Shopify Middleware

On August 28, 2025, [Shopify will sunset the ability to customize your `checkout.liquid` template](https://shopify.dev/docs/themes/architecture/layouts/checkout-liquid).

Newly created stores on the Shopify platform will already notice that they cannot use this template to customize their payment steps, thank you, and order status pages. Shopify is reigning in control over these pages and forcing merchants to migrate to [Checkout Extensibility](https://www.shopify.com/plus/upgrading-to-checkout-extensibility?shpxid=169152ee-9333-4686-13FB-D40F49B3F520). [Recent articles](https://www.shopify.com/plus/customers/monos) published by Shopify promote Checkout Extensibility as the faster and more maintainable way to extend your store’s checkout experience.

Unfortunately, with limited control over the checkout, thank you, and order status pages, merchants have also lost the ability to place tracking pixels on these pages. To remedy this, Shopify has introduced [Web Pixels](https://shopify.dev/docs/apps/marketing/pixels). Web Pixels can be either standalone (Custom Pixels) or part of a Shopify App (App Pixels), and merchants can use them to track both predefined and custom analytics events.

In this article, we’ll examine the inner workings of App Pixel and Custom Pixels and discuss alternatives merchants can deploy when they need additional granularity in their data.


## App Pixels

App Pixels are part of Shopify Apps that you install: for example, the [TikTok app](https://apps.shopify.com/tiktok) provides an App Pixel out of the box–you just need to enable it from the Shopify Admin.

There are several benefits to using App Pixels over adding custom tracking code to your theme: the new structure simplifies the installation and removal of the pixel, allows you to comply with customer privacy regulations out of the box, and streamlines the integration of your tracking logic across different types of checkout (e.g., Shop Pay vs. one-page vs. three-page checkout).

While this new approach to tracking pixels is a significant step forward, not every platform has a Shopify App available; therefore, not every platform exposes an App Pixel. If your tracking platform does not have an App Pixel you can install, you might need to go with Custom Pixels.


## Custom Pixels

Custom Pixels can be used to integrate tracking platforms that do not expose an App Pixel or when you want to track a custom event or datapoint. Your pixel can subscribe to a [fixed set of events that Shopify publishes](https://shopify.dev/docs/api/web-pixels-api/standard-events) or to [custom events](https://shopify.dev/docs/api/web-pixels-api/emitting-data) published by your theme and send the information to an external service.

Similar to App Pixels, Custom Pixels can be enabled and disabled through the Shopify Admin, and they automatically conform to the customer’s privacy preferences, which makes them a powerful tracking solution fully integrated within Shopify.

With that said, Custom Pixels also have their limitations.

First of all, Custom Pixels [are sandboxed in iframes](https://shopify.dev/docs/apps/marketing/pixels#lax-sandbox-custom-web-pixel). Because of that, you might run into limitations with specific tracking scripts. We recommend working with your tracking platform to resolve these issues whenever possible.

Secondly, Custom Pixels only have access to a limited set of data. During a recent migration from custom checkout scripts to Web Pixels, we encountered a limitation on some Custom Pixels, specifically around conversion tracking. By default, Shopify publishes the `checkout_completed` event. As part of this event, Shopify [sends along limited order- and customer information](https://shopify.dev/docs/api/web-pixels-api/standard-events/checkout_completed). However, The tracking tags installed on our store used additional information, like the customer order count and type of purchase, that we originally included in the checkout script.

If you run into such limitations, there are a few alternatives you can try. That being said, each comes with trade-offs, and you should ensure the additional implementation and maintenance effort is worth it.


## Server-Side Tracking

Instead of relying only on Web Pixels, you can use server-side tracking to enrich (or replace) the data sent to your tracking platforms. Because this logic is not running in the browser, you can call the Admin API and access attributes that would otherwise not be available through the Storefront API.

This is a significant advantage, but it comes at a cost: you’ll have to manage custom code that runs on a separate server (or on a platform [such as Gadget](https://nebulab.com/blog/custom-shopify-automations)), and you will not be able to benefit from Shopify’s primitives for Web Pixels, putting the onus on you to deal with aspects such as privacy preference compliance.

An interesting middle ground is to use the [Shopify Flow](https://apps.shopify.com/flow) app. With the ability to [send HTTP requests](https://help.shopify.com/en/manual/shopify-flow/reference/actions/send-http-request) and the [new action to run custom JavaScript code](https://help.shopify.com/en/manual/shopify-flow/reference/actions/run-code), Flow gives you a robust set of tools to send information to an external API with attributes that your Web Pixels or frontend logic cannot easily access. You’ll still need to maintain the logic required for your solution, but Shopify will at least take care of hosting and executing it.


## Checkout Extensions

One of the benefits of the new Checkout Extensions system is that you can inject custom logic and UI into your checkout. Shopify allows extensions [to publish custom analytics events](https://shopify.dev/docs/api/checkout-ui-extensions/2024-01/apis/analytics) with any attributes you want. As Checkout Extensions have fewer restrictions than Custom Pixels, they can be used to pull extra information from the Storefront API and emit a custom analytics event. Your Custom Pixel can then send this event to any third-party tracking platform.

The implementation and maintenance cost here is relatively low: as long as your Checkout Extension adheres to the official APIs, this can be a reasonably robust solution. However, because Checkout Extensions can only access the Storefront API, you will have access to a more limited dataset than with server-side tracking.

You will also need to set up a custom Shopify app on your store and expose the extension to your theme. Luckily, Shopify makes this relatively easy by providing robust tooling and hosting the app directly, which means you don’t need external servers.


## Session Storage

Finally, another approach is to use the browser’s Session Storage to temporarily store attributes as the customer browses your store. You can then retrieve these attributes from your Custom Pixel at checkout. 

For example, you could use Session Storage to store a referrer URL here or the type of order the customer is completing (OTP vs. Subscription) _before_ checkout starts. Custom Pixels have access to Session Storage, which means they can read these attributes when the `checkout_completed` event is fired and forward them to your tracking platform.

Using Session Storage is the simplest way to add additional context to any analytics event: there is no need to set up a custom Shopify app, as all the logic can live in your theme and Custom Pixel. Additionally, in contrast to Checkout Extension, it not only allows you to include additional data that you read from Shopify’s API but also to collect behavioral data while the customer is browsing your store.


## Balancing Data Enrichment with Maintenance Effort

Web Pixels are a robust tracking solution fully integrated within Shopify’s ecosystem.

With more platforms getting on board, App Pixels are quickly becoming a straightforward and reliable solution for installing tracking pixels. In addition, Shopify enforces that the customer has opted into data collection before enabling these pixels, which is a step that is often overlooked when implementing tracking tags on a storefront.

Custom Pixels have some rough edges: their sandbox allows Shopify to enforce similar privacy constraints as for App Pixels but also creates situations where tracking tags don’t work, leaving merchants at the mercy of the tracking platform to build an App Pixel or to update their tracking script.

Finally, when neither App Pixels nor Custom Pixels provide the right data, you can consider alternatives such as Server-Side Tracking, Checkout Extensions, or Session Storage.

We work closely with business stakeholders to determine what events and data we need to track and how the data will be used. We then use that information to build a solution that will satisfy the brand’s needs while also minimizing the technical maintenance burden.

If you are migrating to Checkout Extensibility or need assistance with your existing tracking setup, [don’t hesitate to reach out!](https://nebulab.com/contact-us)

Web Pixels on Steroids: How To Enrich Your Shopify Analytics

In the complex world of e-commerce technology, Shopify stands out as a beacon for businesses eager to establish or expand their online presence. Its user-friendly interface, coupled with a vast ecosystem of apps and integrations, has made it the go-to platform for merchants. Still, the convenience offered in the off-the-shelf package is not enough for everyone.

While Shopify's app store provides many easy-to-install solutions that promise quick wins, the reality is that the more complex your business needs, the less likely you'll find an app that fits the requirements. And, as businesses grow and operations become more complex, the limitations of a simple Shopify build become more and more apparent until they bring businesses to a crossroads: either simplify operations to fit into Shopify’s boundaries, or heavily customize Shopify to play by their rules.

The former path might be acceptable and sometimes even advisable for smaller stores. Building complex Shopify customizations requires significant resources and can be a source of [technical debt](https://nebulab.com/blog/shopify-technical-debt); as such, these projects should always be justified by a clear and compelling ROI.

But for brands in the upper midmarket/enterprise segment, building more complex automations and customizations on top of Shopify often makes perfect sense: these companies have complex internal workflows, custom tooling, and nuanced policies, and their e-commerce platform must learn to adapt and play nice with the existing ecosystem.

Luckily, Shopify’s ecosystem comes with rich tooling designed to create custom apps and integrations. In this post, we'll delve into some of these tools. More specifically, we’ll cover Shopify Flow, Zapier, e-commerce iPaaS Solutions, Gadget, and Greenfield Apps, exploring their pros and cons, ideal use cases, and some examples of the customizations they enable.


## Shopify Flow

[Shopify Flow](https://help.shopify.com/manual/shopify-flow) is a tool built into Shopify that allows creating automations without leaving the platform. It's a basic yet powerful way to respond to events generated within your online store (e.g., a new order being placed) with a set of actions (e.g., sending an email to your staff).

**Pros:**

* **Seamless Integration:** It’s designed specifically for Shopify, ensuring a smooth integration with your store. It’s Included in Shopify for free; no need to pay for extra software.
* **User Friendliness:** Shopify Flow comes with a visual workflow builder that requires no coding, making it accessible to non-technical users.
* **Third-Party App Support:** Shopify apps can extend Shopify Flow by adding their own triggers and actions, which expand the possibilities of the tool. This functionality is only available to Shopify Plus merchants.

**Cons:**

* **Complexity Limitations:** While powerful, Shopify Flow does not always cater to highly intricate integration needs that require custom coding.
* **Partial Support for External API Calls:** You can create an action that performs an API request to an external service (if you’re on the Shopify, Advanced, or Plus plan), but you cannot use the data you receive in any way. Shopify has committed to solving this in 2024.
* **Partial Support for External Emails:** At the moment, it's not possible to send emails using Shopify Flow, except for emails to staff members or as part of email marketing automations. You cannot send transactional emails to your customers or anyone else.

**Ideal Use Case:** Shopify Flow is your go-to for automating operational tasks within Shopify's ecosystem, particularly if you're a Shopify Plus user and can use all of the functionality it offers. It's ideal for businesses looking to streamline processes like tagging high-value customers for exclusive offers or automating restock notifications.

**Example Customization:** Automating the tagging of VIP customers based on their spending history and automatically enrolling them in an exclusive loyalty program.

## Zapier

[Zapier](https://zapier.com/) can be a good alternative to Shopify Flow, if you find its limitations unbearable. Via the Zapier app for Shopify, you can connect Zapier to your Shopify store and pick from an extensive list of triggers and actions to build your automation.

**Pros:**

* **Wide Range of Integrations:** Zapier can connect Shopify with over 3,000 web services, facilitating many different kinds of automations.
* **No Coding Required:** Zapier’s interface is similar to Shopify Flow, but offers even more power by allowing you to build more complex, more robust automations.
* **Rapid Deployment:** You can quickly set up new integrations and automations without the time and cost associated with custom software development.

**Cons:**

* **Pricing:** Zapier’s costs can quickly escalate as you increase your usage of the platform and build more complex workflows.
* **Dependent on Third-Party Connectors:** Even though it boasts more integrations than Shopify Flow, Zapier still relies on the availability and limitations of third-party connectors.

**Ideal Use Case:** Zapier is best suited for businesses that find Shopify Flow too limiting, but still need to build automations or integrate Shopify with other platforms quickly and without custom development.

**Example Customization:** Automatically adding new Shopify orders to a Google Sheets spreadsheet for advanced reporting and analysis.


## E-Commerce iPaaS

Integration Platform as a Service (iPaaS) solutions connect your online store with a variety of other systems, such as ERP, POS, and warehouse management systems (WMS), facilitating the automation of business processes across platforms. There are plenty of iPaaS solutions that integrate with Shopify–our favorite are [Patchworks](https://www.wearepatchworks.com/), [VL OMNI](https://vlomni.com/), [High Cohesion](https://highcohesion.com/), and [Pipe17](https://pipe17.com/).

**Pros:**

* **Connector Ecosystem**: Unlike Zapier, which is a generic automation platform, e-commerce iPaaS platforms specialize in connecting e-commerce platforms like Shopify with CRM, ERP, POS, and WMS systems.
* **Data Integrity:** E-commerce iPaaS platforms were designed to ensure data consistency across platforms, reducing synchronization errors and improving operational efficiency.
* **Bespoke Support:** with most iPaaS platforms, you can typically engage their customer support or professional services team to build connectors that are not already available.

**Cons:**

* **Integration Complexity:** Setting up more sophisticated connectors and automations may require technical expertise to configure and manage.
* **Cost:** The investment required to use an iPaaS reflects its enterprise-level capabilities, making it more suitable for larger businesses with complex needs. Most platforms will charge you per connection or event (e.g., a new product being created).

**Ideal Use Case:** E-commerce iPaaS solutions are ideal for medium-to-large businesses that require robust, real-time integrations between Shopify and other enterprise systems.

**Example Customization:** Integrating Shopify with an ERP system to automate order management, inventory management, and financial reporting, streamlining operations and reducing manual errors.

## Gadget

[Gadget](https://gadget.dev/) is a powerful full-stack serverless platform that allows building and hosting custom Shopify Apps, skipping all the repetitive tasks and accelerating the development cycle of your custom app. Through Gadget, you can accomplish all the automations and integrations that are not possible with off-the-shelf apps and integrators.

**Pros:**

* **Rapid Development:** Gadget offers a rapid development environment for Shopify apps, reducing time to market and human error.
* **Scalability:** Gadget is built to handle high volumes of data and traffic, making it suitable for growing businesses.
* **Developer-Friendly:** Gadget provides advanced tools and resources tailored for developers who need to create sophisticated apps, like Shopify API version management and pre-built React frontends that are compatible with Shopify’s security policies.

**Cons:**

* **Learning Curve:** Developing with Gadget requires a significant amount of technical knowledge, making it hard to access for non-developers.
* **Cost:** Custom apps may involve higher initial development costs compared to simpler integration approaches.
* **Single Environment:** As of today, multi-environment applications (staging+production, for example) are not supported. However, Gadget claims the feature will be released soon.

**Ideal Use Case**: Gadget is a powerful choice for tech-savvy teams looking to build a private Shopify app for their brand as quickly as possible.

**Example Customization:** Creating a custom loyalty program that’s not supported by any off-the-shelf loyalty apps for Shopify.


## Greenfield Apps

When none of the tools above is capable of fulfilling our complex business requirements, we are left with one extra solution, probably the most flexible one: building a custom Shopify app completely from scratch. We call these “Greenfield Apps.”

Greenfield Apps can extend the functionality of your Shopify store in whatever way you want, as long as your desired workflow is supported by Shopify’s APIs.

**Pros:**

* **Malleability:** Greenfield apps can be designed to meet your exact business requirements, offering unparalleled flexibility.
* **Direct Integration:** You can use greenfield apps to interact with all of Shopify's APIs, enriching your online store with custom business logic, Storefront and Admin UI components, and complex automation and integration workflows.
* **Technical Scalability:** Greenfield apps can grow with your business, accommodating new features and processes as needed, without financial or technological lock-ins.

**Cons:**

* **Development Cost**: Custom development is typically more expensive and time-consuming than pre-existing solutions.
* **Maintenance Effort:** Greenfield apps require ongoing maintenance and updates to ensure compatibility with Shopify's evolving ecosystem. \

**Ideal Use Case:** When your business requires unique functionality that cannot be addressed with existing apps or tools, greenfield Shopify apps provide a solution tailored specifically to your needs.

**Example Customization:** A bespoke app that provides a UI for a marketplace’s vendors to update product prices and availability, and instantly propagates those updates across multiple warehouses within your Shopify storefront.

## Complexity Is Not Always a Bad Thing

While Shopify's app ecosystem offers a solid foundation for run-of-the-mill retailers, expanding beyond these boundaries unlocks new levels of operational efficiency, customization, and customer satisfaction.

When considering your options for customizing your e-commerce store, remember that the right choice depends on your needs, budget, and technical capabilities. Make sure that you’re factoring in all of these elements before committing to a specific solution.

Building custom features and integrations may seem daunting, and might require resources and expertise that you don’t have in-house. But at the end of the day, this growing complexity is often a testament to your brand’s growth and the need to evolve your customer experience.

If you need help launching a custom feature or integration for your Shopify store, [feel free to reach out!](https://nebulab.com/contact-us) Our engineering team would love to help you figure out the right solution.


Building Custom Shopify Automations, From Beginner to Pro

Have you ever struggled with a simple addition to your Shopify store turning into a nightmarish project, full of intricacies and edge cases? Or maybe you’ve experienced the impatience of looking at your product page take forever to load, longing for the good old days when it showed up instantaneously? Or perhaps you’ve run into weird UI bugs caused by two of your apps not playing nice with each other?

When you launch a new Shopify store, everything’s fantastic: the theme is beautiful, the pages load fast, and the apps you’ve picked are a joy to work with. It feels like you’ve got everything figured out, and no one and nothing will ever change that.

But after a while, some friction shows up. Implementing new features takes longer. Bugs pop up. Site speed decreases, as does your conversion rate.

Your team (or your agency) now spends more time hunting down the things that are not working than implementing new functionality that could move the needle. But even though everyone’s dissatisfied with the state of things and your business is suffering, no one can pinpoint the root cause or figure out a definitive solution.

Starting from scratch looks like the only option, so that’s what you do. You change agencies, rewrite your theme, and call it a day. Unfortunately, the rewrite only helps temporarily: give them enough time, and things will revert to their original state, and the cycle will start all over again.

Sounds scary, doesn’t it? And yet it’s a story that we’ve heard from many Shopify merchants, disenchanted with their agency, internal team, or the Shopify ecosystem as a whole.

The good news is that it doesn’t have to be like this. There’s a way to keep your ecommerce store from degrading over time; all it requires is a more thoughtful approach to store development. In this blog post, we’ll outline what that approach looks like, and how you can adopt it.

But before we do that, we need to introduce the concept of technical debt.

## What Is Technical Debt?

Technical debt, often called just “tech debt,” refers to the compromises made in a system for short-term gains, which may lead to more complex maintenance and updates in the long run. It is the practice of taking shortcuts: installing unvetted apps for the sake of shipping a feature, implementing untested JavaScript “hacks” in your theme, breaking best practices for theme maintenance, or failing to keep up with the latest Shopify API updates.

These solutions help you move faster and will not kill your store in the short term, which makes them so appealing in the first place. But in the long term, the consequences will show up in the form of bugs, lower site speed, a slowdown in development velocity, and, in extreme scenarios, a decrease in conversion rate.

Unfortunately, Shopify’s marketing can be misleading when it comes to technical debt: the promise is that, by using Shopify, merchants will never need to worry about technology, and by extension, they will never need to worry about technical debt.

That is only partially true: while Shopify handles a lot of responsibilities for merchants, a merchant’s theme and app stack is still for the merchant to maintain, and it can accumulate technical debt just like any other software. Your theme can either be a beautifully architected piece of technology, highly performant and easy to evolve, or a hot mess of obscure hacks and patches no one understands anymore. You, the merchant, are ultimately responsible for deciding where you want this pendulum to swing.

But in practice, what are the sources of technical debt in Shopify that cause stores to lean one way or the other? Here’s a non-exhaustive list, but keep in mind that there are additional factors that are often unique to each store:

* **Multiple stores:** even after the advent of Markets and B2B in Shopify, many merchants keep using multi-store setups when they are not needed. Because each store is independent and stores can diverge from each other, this setup can be a significant source of technical debt, increasing the cost and complexity of making changes.
* **Too many apps:** Shopify’s blessing–its app ecosystem–is often its curse. When we audit Shopify stores, we are often shocked by how many apps the average store has installed. Often, not even the merchant can explain what all the apps do. This is the #1 source of bugs, compatibility issues, and a steep increase in license fees.
* **Too much JavaScript:** some custom themes present a large amount of JavaScript code, often using external libraries such as React, Angular, or jQuery. This complexity, which is sometimes uncalled for, makes it harder for developers to find their way around a theme, slows down your website, and introduces bugs.
* **Large Liquid files**: similar to the point above, Liquid files that are hundreds of lines of code quickly become hard for developers to understand and change, to the point where they might be deemed completely unmaintainable.
* **Outdated code:** if your store is not leveraging metaobjects or not using the full potential of Online Store 2.0, you might end up with weird hacks and workarounds to implement functionality that is now natively available in Shopify. Apps can compound this problem because they are sometimes slow to adopt new Shopify APIs and capabilities, reducing the flexibility and optionality of their user base.

There are additional factors that are not technical debt _per se_ but often lead to technical debt over time: examples of these would be the lack of a defined QA process for theme changes, which increases the likelihood of bugs, or the lack of theme documentation, which makes it harder for unfamiliar developers to find their way around the project.

## A Three-Step Approach to Managing Shopify Technical Debt

Managing technical debt in a Shopify store can be tricky for inexperienced merchants and developers. However, a structured approach can go a long way in effectively controlling it. Here’s the three-step process we typically adopt when we work with a merchant.

### 1. Measure the Business Impact

Before tackling technical debt, it's essential to understand the extent of the problem.

In traditional software projects, there are tools that attempt to measure the health of your code. These tools typically ingest your entire codebase and produce a “quality” score that tells you the overall state of the software and what areas you should improve.

The bad news is that most of these tools don’t work with Shopify themes because they’re structured differently than most other software. The good news is that, in our experience, such tools are ineffective: technical debt only matters insofar as it _actually_ impacts your business. Code quality, as measured by a machine, is rarely a good proxy for business impact.

Instead, you want to measure the effects of technical debt on your store’s real-world performance. There’s no one-size-fits-all metric here, but here are some that we’ve used:

* **Defect rate,** which measures the number of features your team has shipped that introduced one or more bugs in the customer experience.
* **Cycle time,** which measures the time it takes for your team to implement a change after that change has been prioritized.
* **Site speed,** which should be pretty self-explanatory.

Both defect rate and cycle time can be measured with a good project management tool, while site speed is typically measured with tools such as PageSpeed Insights.

With all these metrics, what matters most is not their absolute value but their directional trend over time: if they’re getting better and not worse, you’re moving in the right direction and can double down on your current approach.

### 2. Establish a Solid Foundation

Once you have a good grasp of the extent of the problem, the next step is to ensure there are no obvious sources of technical debt in your Shopify setup.

These are the aspects we typically focus on:

* **Leverage native Shopify features**: by using native functionality as much as possible, you are reducing the need for ongoing maintenance. Whenever you diverge from the built-in functionality, you should always consider the balance between innovation and the additional complexity you’re introducing into your store.
* **Minimize third-party apps**: in addition to increasing your license fees, each app you install into your store introduces more complexity, potentially slows the website, and can lead to bugs in the customer experience. Vet all the apps you install and ensure they are needed.
* **Adopt a version control system (VCS):** a VCS makes it much easier to document the changes developers are making to your theme, and to roll back to a previous version of the theme in case a bug pops up. From a technical standpoint, there’s no reason not to have a VCS in place for your Shopify theme.
* **Set up a test store:** a staging environment (sometimes called a “test store”) allows you and your ecommerce development team to test your changes safely before rolling them out to your customers. The caveat is that you will likely need to install all your apps in the staging environment, increasing your license fees.

While this is just the beginning, it will give your team an initial foundation they can build upon.

### 3. Prevent and Reduce Debt Over Time

With the basics in place, you can now adopt team-wide policies to help your team minimize the technical debt you introduce over time.

These are some of the policies that we adopt:

* **Call technical debt by its name:** if you only do one thing outlined in this article, it should be this. The #1 reason technical debt keeps growing is that developers do not have the technical understanding or psychological safety to talk about it. Ensure everyone is familiar with technical debt and comfortable calling out when a corner has been cut. A recurring team retrospective can be very helpful here.
* **Perform technical code reviews:** encourage developers to review each other’s code whenever a change is introduced. This means that developers will need to schedule time for code reviews, and your development velocity will slow down a bit, but the quality of the end product will benefit tremendously.
* **Establish a structured QA process**: ideally, QA should be done on every new change by your development team, who should be familiar enough with your store to understand whether a feature meets all the acceptance criteria. If that’s not possible, you can also designate the person in charge of website development.
* **Set time aside for tackling technical debt:** in the past, Shopify shared their internal strategy for dealing with technical debt, the [25 Percent Rule](https://shopify.engineering/technical-debt-25-percent-rule). It might not work for everyone, but having a clear understanding of how much time is acceptable to dedicate to refactoring technical debt will create a safe space for developers to work on it.

Some of these policies might be overkill for small stores, while others must be adapted to your needs. Ultimately, it all boils down to how much technical debt impacts your store and how many resources you can dedicate to fighting it.

## Technical Debt Is a Tool: Learn to Use It!

With this entire article focusing on eliminating and preventing technical debt in your Shopify store, you might be tempted to think that technical debt is something to be avoided at all costs. The reality is a bit more nuanced.

Like financial debt, technical debt is a tool: cutting corners helps you move faster at critical times of your business, such as before a big launch or public holiday.

And _just like_ financial debt, technical debt must also be paid off at some point. If you ignore it, its adverse effects will compound over time, severely impacting team morale and dragging down business performance.

Leveraging technical debt thoughtfully and intentionally is critical to a merchant’s success in the Shopify ecosystem. Doing it well requires a collaborative effort, with clear team agreements and robust processes tailored to your growth stage and team composition.

If you’re struggling with managing technical debt in your Shopify store, [reach out!](https://nebulab.com/contact-us) As a Shopify partner, have worked with some of the largest brands in the ecosystem and can help find the best solution for your store.


How To Manage Technical Debt in Your Shopify Store

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

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.

The Nebulab