Alberto Vena

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

Michela Frecchiami

In our [previous article about cross-cultural design](https://nebulab.com/blog/cross-cultural-ecommerce-design), we delved into the intricacies of crafting online shopping experiences that resonate with diverse cultural backgrounds. We explored how Cross-Cultural Design can be the beacon that guides brands through the complexities of global expansion, emphasizing that a one-size-fits-all approach is rarely practical.

This time, we'd like to focus on a particular design trend that originated in the East and is gaining traction worldwide in specific market segments.

Characterized by busy interfaces and seemingly chaotic information taxonomies, this model stands in stark contrast to the more streamlined, search-centric user experiences we’re used to. Browsing for products is an adventure in and of itself: the shopping journey is akin to a digital bazaar, buzzing with energy, and each click leads to unexpected finds.

This trend has a name—it’s called *shoppertainment*—and it’s being popularized in the West by Chinese e-commerce marketplaces such as Shein and Temu.

Today, we’ll look at what shoppertainment is exactly, why it works so well, and what lessons we can learn from its most prominent adopters.

## How Shein and Temu Drive Customer Engagement through Shoppertainment
Temu, pronounced “tee-moo,” is an online superstore for virtually everything—from home goods to apparel to electronics—that made its Super Bowl debut in 2023.

Temu encourages consumers to “shop like a billionaire” and offers products at surprisingly low prices. It has quickly become [the most downloaded app](https://www.statista.com/statistics/1417955/most-downloaded-marketplace-apps-worldwide/), surpassing rivals Amazon and Walmart, not just in the United States but in the entire world.

With low prices and cluttered design, the personalized and gamified shopping experience Temu offers has drawn comparisons to Shein, [the Chinese fast fashion upstart](http://www.cnn.com/2021/08/14/business/shein-china-fast-fashion-intl-hnk/index.html) that also offers a wide selection of inexpensive clothing and home goods and has made significant inroads into several markets, including Europe and the United States.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/05fe639fe020903aa95fffd22a520ba6aaa28a06-1600x1052.jpg?fit=clip" alt="Shein Influencer on Youtube">
</figure>

Shein and Temu have both burst onto the scene in an online-first, fast-moving world. Through social media, influencer partnerships, live-streaming events, and a hefty reliance on performance marketing, they've created a strong brand presence that resonates with their target audience, often overshadowing the more sober, utilitarian approach of marketplaces like Amazon and Walmart.

When exploring the user experience design of platforms like Shein and Temu, it becomes evident that they foster an overwhelming sensory experience.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/77d823a005f01064ebcf0d5aadc49f0a4ea92f62-1600x1052.jpg?fit=clip" alt="Temu user experience">
</figure>

The interfaces of these platforms are a collage of vibrant colors, animated elements, and interactive features that aim to captivate and retain user attention. It's a digital landscape that's always in motion, with pop-ups, limited-time offers, and an endless stream of personalized recommendations designed to evoke the same excitement and urgency one might feel in a bustling street market.

Compare this with Amazon's more conservative approach, where functionality and efficiency are the cornerstones. Amazon's clean and practical design focuses on the ease of finding products through a logical and orderly user interface.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/3130810a416d7ba2c3239d26b5bdf116d0b43d4c-1600x1052.jpg?fit=clip" alt="Amazon browsing experience">
</figure>

These differences mirror broader cultural preferences that Temu and Shein lean heavily into and have managed to “export” outside their original cultural context.

## High-Context vs. Low-Context Cultures and their Impact on Design
In [high-context](https://en.wikipedia.org/wiki/High-context_and_low-context_cultures) Eastern cultures, where communication is often layered and nuanced, the sensory-rich UX design of Shein and Temu does not overwhelm but rather speaks a familiar language.

Furthermore, the digital journey took a mobile-first trajectory in the East, with the majority of the population experiencing the internet for the first time through the screens of their phones rather than desktop computers. This has profoundly influenced how online services, including e-commerce, have evolved in these regions.

Let’s think about Alipay and WeChat, platforms offering a comprehensive range of services from bill payments and banking management to taxi bookings and shopping. For super app users, the process of purchasing a luxury handbag within the same platform used for everyday tasks like paying utility bills is seamlessly integrated, reducing cognitive dissonance.

Conversely, in the more conservative and [low-context](https://en.wikipedia.org/wiki/High-context_and_low-context_cultures) West, Amazon's streamlined approach aligns more closely with communication preferences. The marketplace's structure and navigation are built for efficiency, offering a controlled space that prioritizes the straightforward discovery and purchase of products. Amazon's interface is a testament to the low-context communication prevalent in Western culture, where explicit messages win the day.

And yet, despite the cultural nuances, shoppertainment-centric platforms like Temu and Shein continue to gain traction in the West. What gives?

## The Appeal of Shoppertainment Across Cultures and Generations
As mentioned earlier, Temu and Shein embrace the delight of discovering treasures in a bustling marketplace. The success of these platforms lies in their mastery of discovery-based commerce. They blend AI with an understanding of user behavior to create a personalized and gamified shopping environment. Influencers, social proof, and live-streaming events further enrich this landscape, transforming the act of purchasing into an engaging and social event that feeds on the innate human love for exploration and deals.

Interestingly, this “shoppertainment" model resonates particularly well with Western Gen Z consumers, who are more adaptable to innovative, if less polished, user interfaces. Their shopping habits are motivated by value and the excitement of discovery rather than the aesthetics of the shopping platform. The loud and lively [Y2K stylings](https://www.pcmag.com/encyclopedia/term/y2k-fashion#:~:text=The%20technology%2C%20styles%2C%20dress%20and,Y2K%20problem%20and%20Y2K%20anxiety), playful interactions, and immersive content that dominate these sites speak the language of a generation that craves authenticity and spontaneity over polish and predictability.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/e1c699b758b05bdb646829f956b0ea868f307157-1600x1052.jpg?fit=clip" alt="Shoppertainment and Gen Z">
</figure>

Temu and Shein continue to rise in popularity, and not just with Gen Z. There’s another significant factor contributing to this phenomenon.

While Gen Z may be at the forefront of embracing energetic and interactive digital storefronts, the economic draw of these platforms speaks to the universal appeal of consumerism. Older generations, too, find the cost savings compelling enough to venture into these more animated shopping environments, suggesting that the desire for value can sometimes supersede preferences for a more traditional and subdued browsing experience.

As such, Shein and Temu have tapped into a powerful vein within the consumer market, demonstrating that while the 'shoppertainment' model might be vital to capturing the hearts of younger users, the fundamental drive to consume at the best possible price is a widespread motivator that crosses generational and cultural boundaries.

## Is Global E-Commerce Moving Toward Shoppertainment?
Temu and Shein have not just pioneered the 'shoppertainment' model; they've excelled in it, capturing the hearts of a broad audience with their gamified, discovery-driven approach to commerce. Their success lies beyond competitive pricing or extensive inventories, and it’s rooted in a shopping experience that equally prioritizes entertainment and acquisition. 

Looking ahead, the trajectory of e-commerce design might be steering towards a hybrid model. Incorporating personalized and interactive elements typical of Eastern consumer experiences without compromising the organized simplicity that users appreciate in the West will be critical to the continued success of our domestic marketplaces.

As such, the next challenge in e-commerce design will be to create experiences that resonate not just with a medley of cultural preferences but also with the varied tastes of an international, multi-generational audience.

If you have any questions about shoppertainment or want to understand which principles you can apply to your brand, [feel free to reach out](https://nebulab.com/contact-us)–we’d love to chat!

East, Meet West: The Rise of Shoppertainment in E-Commerce

Marco Trincardi

There’s nothing more frustrating than trying to complete a puzzle, only to realize you’ve misplaced one of the pieces and there’s no way to finish the thing.

But what if you could _build_ that custom piece, designing it with all the right knobs and holes, allowing you to complete the puzzle? Imagine you could also paint it to perfectly complement the puzzle’s design. How amazing would that be?

Well, for real-world puzzles, you’re probably out of luck. But when it comes to computer systems, that’s pretty much what middleware does: just like your custom-built puzzle piece, middleware is custom software that streamlines the connection between different business applications, systems, or APIs, allowing them to communicate and collaborate effectively.

In e-commerce, middleware is usually found in enterprise applications, where companies often need to connect their proprietary systems to third-party vendors. However, middleware is not just for e-commerce giants: in specific scenarios, smaller brands can also use middleware to enhance the agility and robustness of their e-commerce setup.

In this article, we will explore the typical use cases for middleware software, the pros and cons of building your own, and how to do it correctly.


## When Does an E-Commerce Brand Need Middleware?

When you’re a large enterprise company, you typically have a dedicated IT department that handles system integration, and the responsibility for deciding when to buy or build middleware software lies with this department. In this case, you don’t need to worry about making such decisions.

But if you’re a smaller brand, you might be unsure when to think about middleware. Here are a couple of scenarios:


* You have found the perfect 3PL provider, but they don’t support your e-commerce platform out of the box.
* You want to use your existing ERP integration to generate invoices for your B2B e-commerce customers. However, the way your platform’s connector sends order data to the ERP is incorrect, and the resulting invoices are unusable.

In both cases, you could buy or build middleware software to integrate with the new system or adjust your existing integration. Just as a custom piece connects different sections of a puzzle, the middleware will bridge your different vendors together, ensuring they produce the desired results.

In general, whenever you want to insert yourself between different applications to streamline or adjust their data flow, middleware is the right solution.

With that said, adding middleware to your infrastructure is not free: let’s look at the complexity it can create and how to manage it.

## Middleware Seems Easy Until It Isn’t

Most of the time, your first middleware implementation is easy to build. You start from a well-identified business need, and the project goes almost flawlessly. Once online, you might find some edge cases that were not covered, but it’s usually pretty simple to address them. Everything’s under control, and everyone on your team is happy.

After a few weeks or months, you identify new business needs that are not satisfied by your existing system. Since the first iteration went well, you feel confident adding new functionality to the middleware–perhaps by integrating with a new external system.

As you work to reconcile the different data schemas, you feel like you’re getting pulled in too many directions: data management becomes more complicated, caching and scalability problems start popping up, and not even the people who built your middleware stack are quite sure of the data transfer flows anymore.

Back to the puzzle metaphor, the knobs and holes are the communication channels, while design and color are the data model that needs to be blended. You have already put many different knobs and colors in one giant puzzle piece, and every time you need to connect to a new part of the puzzle, you keep changing it, adding knobs and holes, and trying to blend the colors harmoniously.

What was simple and neat in the beginning has become increasingly complex over time.

It’s also interesting to note that the perception of middleware complexity does not increase linearly. Usually, it has a discontinuity point: everything seems smooth and easy, but once you reach the discontinuity, everything suddenly becomes complex and demanding. In technical literature, this condition is called _complexity creep_.

So, where does this complexity come from, and how can you manage it?

## Managing the Complexity of Middleware

Now that you understand the inevitable complexity of middleware, it’s time to look at a few ways to keep it under control. Drawing from years of experience, we've honed some practical strategies to manage and mitigate these challenges effectively.

Let's take a look!


### #1: First of All, Do You Really Need Middleware?

This might sound counterintuitive since this entire article is about middleware, but the best way to keep complexity under control is not to create it in the first place, and the most cost-effective middleware is the one that doesn’t exist.

This isn’t always possible, and middleware software is sometimes a necessary evil. However, we’ve often seen retailers reach for complex custom solutions when the stock functionality of their e-commerce platform or fulfillment provider would have worked just as well.

Before jumping into a middleware project, evaluate your vendors’ capabilities carefully–ideally, reach out to their support team and see if they can suggest any alternatives that will work out of the box.

Even when there are no alternatives, consider whether reframing your original request might lead to a much simpler solution: sometimes, the cost and effort involved in buying/building and maintaining your middleware doesn’t justify the return on that investment.

As a rule of thumb, if you can’t build a compelling business case around your middleware stack, and the only reason you’re building it is to make your life slightly easier, it’s probably better to hold off on the project until you can identify a pressing need.


### #2: Acquire a Bird’s-Eye View of Your Workflows

When you decide to build middleware, start the project by mapping the existing business processes. Don’t just focus on the process impacted by your middleware; instead, make sure to also cover upstream, downstream, and adjacent dependencies.

Sound too abstract? Let's make it more concrete with our ERP example:

1. First, describe what is happening in your internal and external software applications from when the order is made to when the invoice is sent.
2. Then, expand upstream, asking questions such as: “What are some of the promotions or discounts that could be applied to the order? How do we reflect that in the invoice?”
3. Finally, expand downstream, asking questions such as: “Does the invoice generation process only impact the ERP? How does it affect our CRM, supply chain or legacy systems?”

Back to the jigsaw puzzle metaphor, this process is like acquiring a view of the entire puzzle, and not just of the knobs and holes that surround our custom piece. Building this comprehensive understanding of your business workflows not only aids in your current middleware project but also helps you anticipate and manage future complexity.

The best part is that it doesn’t take ages to create this map: at Nebulab, we usually run a dedicated eight-hour workshop, remotely or in-person, to build the first version; we then spend a couple of hours now and then when we need to update it.

### #3: Adopt an Evolutionary Approach

Having a broad view of your business workflows doesn’t mean you have to build your entire middleware stack in one sitting. Quite the contrary!

The best approach is to build incrementally, one use case at a time, and get feedback from real-world usage. This feedback is essential to guide you in future development, refine your processes, and spark new ideas. It also makes it easier and more sustainable, reducing the chance that a middleware bug will severely impact your customer experience.

See it this way: The broader view tells you which direction to go, while the evolutionary approach tells you to put one foot before the other rather than making giant leaps. You have a complete vision of your puzzle, but you still build your custom piece one knob at a time.

## Your Middleware Is Critical Software

Once created, your middleware will become a central component of your brand’s tech stack: most likely, it handles your customer, order, or shipment data; it’s a critical piece of your customer experience, and it will negatively impact your operations in case of malfunction.

Because of this, middleware development should be considered mission-critical and treated accordingly: involve established vendors and highly skilled developers–ideally, someone with a track record of building high-traffic systems and who knows how to create resilient, high-quality software through best practices and automated testing.

In e-commerce, these competencies are rare. If you don’t have them in-house or in your partner network, [feel free to reach out!](https://nebulab.com/contact-us) We’ve supported tens of brands just like yours in designing, building, and maintaining their middleware solutions, and we know what it takes to make this journey as smooth as possible.


How To Design and Maintain E-Commerce Middleware

Alessandro Desantis

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

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

## What is a tech stack?

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

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

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

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

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

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

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

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

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

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

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

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

### eCommerce platform

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

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

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

### Payment processing

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

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

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

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

### Logistics

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

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

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

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

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

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

### Content management

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

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

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

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

### Marketing

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

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

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

### Customer support

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

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

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

### Business intelligence

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

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

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

## 8 tips for building your tech stack

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

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

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

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

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

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

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

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

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

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

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

## Do you need help building your tech stack?

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

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

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

How to Build Your eCommerce Tech Stack

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

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

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

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

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

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

Let’s dive in!

## Online Store: Small but Mighty

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

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

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

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

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

What’s the catch, then?

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

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

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

## Hydrogen: Let’s Lose Our Heads

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

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

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

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

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

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

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

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

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

## Commerce Components: The Composable Way

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

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

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

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

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

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

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

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

## So, Which One Should You Use?

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

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

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

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


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

Picture this: You run an eCommerce store, and business is booming in your home country. Feeling confident, you decide to expand into new markets. You translate your website into a few languages, but something's amiss. Your sales aren't hitting the expected numbers, and customers seem less engaged. What went wrong?

This is where Cross-Cultural Design comes to the rescue. Cross-Cultural Design (CCD) recognizes that every culture is unique and influenced by its values, traditions, and preferences. Ignoring these cultural nuances can lead to missteps, missed opportunities, and the alienation of potential customers.

In this article, we'll take you on a laid-back journey through the exciting world of CCD, explaining why it's a game-changer and how to navigate it effortlessly.

## The Principles of Cross-Cultural Design

Thinking about how cultural differences can influence users' needs and expectations isn’t an easy task, and we at Nebulab know it very well: we’re not only fully distributed, but we also work with brands from all over the world. Local preferences, navigation, and information hierarchy are just some of the aspects that can be influenced by cultural, behavioral, and economic elements.

In theory, User Research should help designers understand what their audience expects from digital interactions. Unfortunately, most behavioral research studies–which User Research practitioners take a lot of inspiration from–[are based on Western subjects](https://www.youtube.com/watch?v=Ho6OlPrD7sA)). This leads to the majority of design and user experience benchmarks being Western-centric, which creates obvious problems for teams that are designing for a non-Western audience.

In light of these challenges, broadening our perspectives becomes even more difficult: without reliable data and benchmarks, how can designers operate effectively without sacrificing speed?

That’s where Cross-Cultural Design comes to the rescue: rather than providing a set of steps to follow, it offers a set of principles that designers should keep in mind when operating outside their zone of “cultural comfort.” These principles will guide you to approach your work differently, which, in turn, will help you make better choices for your design, content, and technical strategy:

* **Embrace Cultural Immersion**: Dive into the culture you're designing for, immerse yourself in its nuances, and understand its values, traditions, and aesthetics. This deep understanding will help you create designs that resonate with the local audience.
* **Research Creative Communities**: Explore the creative communities within the culture. This involves understanding how artists, designers, and local creators express cultural identity. Drawing inspiration from these communities can enrich your design.
* **Work with Experts**: Collaborate with experts or individuals with in-depth knowledge of the culture. Their insights can provide invaluable guidance and ensure your design is culturally sensitive and authentic.
* **Question Assumptions**: Challenge assumptions and preconceptions about the culture. Be open to reevaluating your design choices based on real-world insights and user feedback rather than relying on stereotypes or biases.
* **Prioritize Flexibility**: Design with flexibility in mind. Recognize that cultures evolve, and your design should adapt to changing norms and preferences. A flexible design can better withstand the test of time and evolving cultural trends.

Now that we've explored these guiding principles, let's dive into two crucial concepts closely related to cross-cultural design: internationalization and localization.

## Internationalization and Localization: You Need Both!

The most fundamental challenge teams face when working on a cross-cultural project is ensuring the content, branding, and design are flexible enough to accommodate multiple languages, nationalities, and cultures. This process is called _internationalization_ (often abbreviated as _i18n_). **Internationalization involves creating digital experiences that work across cultures.**

On the other hand, **localization (_l10n_) involves tailoring a product to a specific culture.** Localization encompasses modifying UIs, adjusting layouts and styles, revising content and language, and tailoring and enhancing the user experience to suit the needs of the particular audience you’re designing for.

In other words, while internationalization is more about having a framework in place to adapt your product to a global audience, localization is about doing the actual work of adapting your product for each audience you want to serve.

Because internationalization mainly falls on the shoulders of your engineering team, we won’t focus on it in this article. Different eCommerce platforms and software libraries have different internationalization capabilities–make sure your engineering team is aware of any cross-cultural requirements and uses that information to inform their technical choices.

Instead, let’s explore the most common aspects that you need to consider when _localizing_ your design systems and digital experiences, particularly when it comes to eCommerce.

### Names and Addresses

It's essential to understand that cultural differences extend to the most basic elements of your user experience, such as how names or addresses should be collected and formatted.

For example, when we designed the checkout form for a Pakistani marketplace, we learned that Pakistani individuals will often have a first name, a middle name (which is typically their father's name), and a last name (family name or surname). With that requirement in mind, we decided to scrap the “First name” and “Last name” fields, typical of Western cultures, in favor of a single “Your name” field instead.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/3cc7341fef23a9a7996314c04bb0f694078be97b-1600x1052.jpg?fit=clip" alt="Unified field for first, middle and last names">
</figure> 

The same applies to addresses: in the form below, you might have noticed that there is no ZIP Code field–that’s because there are no ZIP codes in Pakistan. For our client [Framework](https://frame.work/), on the other hand, we’ve had to adapt the ZIP code field to allow both 3+2 and 3+3 codes in Taiwan.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/9ba2719bc3b73d7a9af55685588fbde123c4fbf8-1600x1052.jpg?fit=clip" alt="Framework's shipping address form for Taiwan">
  <figcaption>Taiwan’s introduced 3+3 ZIP codes in 2020 to improve mail sorting efficiency.</figcaption>
</figure>


### Text Direction

One of the most significant layout challenges encountered while localizing a South Eastern client’s eCommerce experience was supporting right-to-left (RTL) text in Lebanon.

That kind of change doesn’t just involve the actual text but also requires shifting the overall content and “mirroring” certain UI elements:

* **Headers, labels, and text should be oriented from right to left**. In eCommerce, that means displaying the brand’s logo on the right and the cart icon on the left.
* **Navigation buttons** must be mirrored, but icons that do not convey direction should remain unchanged.
* **Checkboxes** should be positioned to the right of their corresponding label.
* **Progress bars** should fill in a right-to-left direction.

Later in this article, we will explore tools to assist designers in this process.

### Linguistic Nuances

Very often, translating your UI and content is just the first step. It’s crucial to remember that each language has its quirks and nuances.

A common problem is that UI elements that look good in English might not be suitable for other languages. As an example, the German language allows stringing together multiple nouns to express complex concepts, which leads to some very long words that cannot be readily displayed in a mobile button.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/0e17cec623f050d16c9a7d4dc23019effd576e6c-1600x1052.jpg?fit=clip" alt="German vs. English UI in Framework">
</figure>

Another consideration is that the formatting of numbers, phone numbers, and currencies varies in each language. Using the same phone number or currency format across different languages is bound to cause confusion and friction for the user.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/b949ccdab489f172ff0e28a913d61c54d49da452-1600x1052.jpg?fit=clip" alt="Framework's checkout flow">
</figure>

### Payment Methods

Credit card usage is widespread in Western countries, while digital wallets and cash-on-delivery are preferred in many Asian markets. Adapting payment options to local preferences can dramatically enhance the customer experience and your conversion rates!

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/b8e24cd97481e4b71bb924ac1b5019328afb9c57-1600x1052.jpg?fit=clip" alt="OLX Mall's payment method selector">
  <figcaption>In some countries, cultural, historical, and socio-economic factors led to a deep-rooted preference for cash payments, even in online transactions.</figcaption>
</figure>

### Sign-In Preferences

Even something as familiar as the sign-in process can vary across cultures. In Western markets, users typically register for websites or online services using their email addresses. However, in Eastern countries, most users prefer to use their phone number.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/2a7306fd9abf204f991c15a7cdfab56224db629c-1600x1052.jpg?fit=clip" alt="Sign-in modal that supports phone numbers">
  <figcaption>In many Eastern countries, phone numbers, not emails, are the preferred method identification for creating online accounts.</figcaption>
</figure>

### Social Proof

In the world of eCommerce, trust is the cornerstone of successful transactions. Yet, how trust is built and perceived can vary significantly across cultures: some cultures prioritize the prominent display of security badges for reassurance, while others emphasize customer reviews and testimonials to instill trust in a website.

Understanding these cultural nuances is pivotal in crafting an effective eCommerce strategy that resonates with diverse audiences worldwide.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/ae4f65150f404d46b77a0fd1f3f6f6ea2d4ef6db-1600x1052.jpg?fit=clip" alt="Shop Safely badge in OLX Mall's checkout flow">
  <figcaption>In OLX Mall, we displayed a “Shop Safely” badge through the entire checkout flow.</figcaption>
</figure>

### We’re Not Even Done

If that wasn’t enough, here are a few more aspects you should consider when designing eCommerce experiences for a global audience:

* **Information Density:** Cultural differences can affect how users expect information to be organized. In some cultures, users may love maximalism and appreciate detailed product descriptions, rich user interfaces, and bright colors, while in others, a more minimalist approach might be preferable.
* **Taxation:** How you apply taxes is dictated by regulatory requirements, but different cultures also have different norms for where and when taxes should be displayed. For specific audiences, showing tax amounts in the wrong place or at the wrong time can increase friction and cart abandonment rates.
* **Imagery:** When picking and displaying images, it’s essential to be mindful of each culture’s sensitivities. You also want to be aware of home and mobile internet speeds in the countries you’re serving: serving a 5MB product image to someone on a 3G connection might not be the best idea!

It would be hard–if not impossible–to provide a comprehensive list of all the elements you should pay attention to. Instead, we recommend constantly referring to the principles of Cross-Cultural Design and using them to inform your day-to-day decisions.

## Sharpening Your Toolkit for Global Design

With localization becoming increasingly important, all the most popular design tools support non-Latin languages and offer features that help in designing for cross-cultural projects.

### Use the Right Figma Plugins

Figma's support for RTL languages is relatively new, having been available for about two years. To change the default [text direction](https://help.figma.com/hc/en-us/articles/4972283635863), select the main menu and go to **Text > Text direction**. Then, when you use the Text tool, the text direction will be set automatically.

There are also several plugins available that let you add your translations quickly and easily. Our favorite ones are:

* [Translator](https://www.figma.com/community/plugin/743218037112142643/translator), which boasts support for 130 languages and translates entire pages very quickly, making it an excellent choice for a quick preview of your layouts in various languages.
* [Cube Translation](https://www.figma.com/community/plugin/1205127328344023071/cube-translator), which uses AI to enhance translation accuracy and provides more robust tooling for real-time collaboration and content synchronization.

As always, your mileage may vary, so we encourage you to experiment with a few different plugins and pick the one most suited for your use case!

### Choose Multilingual Fonts

Selecting the appropriate font for an international project can be a challenging task. It's important to note that not all web fonts support multiple languages, and in some cases, you might encounter unreadable rectangular symbols (referred to as "Tofu").

Multilingual fonts are specifically crafted to solve this problem and accommodate various languages. The most comprehensive open-source, multilingual font family is [Noto](https://fonts.google.com/noto) (its name stands for “no tofu”), and it offers support for more than 1,000 languages.

If you want something more unique, [Google Fonts](https://fonts.google.com) provides a variety of fonts that are either multilingual or designed for specific languages–you can easily find them by applying the language filter to your search.

![Hello is written in different languages with Noto font](https://cdn.sanity.io/images/kqgmf0g2/production/f885f7fee73faf86874c394e4ff0d91df07f1849-1600x1052.jpg?fit=clip)

### Adapt Your Images

As we’ve mentioned, a critical aspect of images is cultural inclusivity. Culturally inclusive images are significant as they portray diversity and support representation. If you have a dedicated creative production team, work with them to develop assets that are suitable for your audience. If you don’t, websites like [Unsplash](https://unsplash.com/) have handy search tools to help you find what you need.

Once you have your images, you also want to ensure they’re optimized for your audience’s internet speeds. [TinyPNG](https://tinypng.com/) is often the go-to choice and, despite the name, also works with JPG and WebP files. We recommend pairing it with a robust CDN for optimizing images on the fly.


## Ready To Take On the World?

As explored in this article, culture plays an immense role in shaping how people interact with and perceive the digital shopping experiences we create for them. As you expand internationally, recognizing these influences is not just a consideration but the key to thriving in an increasingly diverse eCommerce ecosystem. Cross-Cultural Design can help you do just that.

If you have questions on how to make these principles work for your team, or need help designing for a global audience, [feel free to reach out](https://nebulab.com/contact-us)–we’d love to chat!

Expanding Your Brand Globally With Cross-Cultural Design

Stefano Sarioli

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

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

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


## 1. Start With the Why

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

A replatform project is a big undertaking from many perspectives:

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

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

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

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

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

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


## 2. Think Brand First, Not Vendor First

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

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

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

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

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

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

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

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


## 3. Account for All the Expenses

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

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

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

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

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

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

## 4. Approach the Work Incrementally

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

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

Here are a few techniques we typically adopt:

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

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

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

## 5. Resist the Urge to Redesign

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

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

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

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

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

## 6. Prioritize the Scary Stuff

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

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

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

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

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

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

## Launch and Celebrate!

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

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

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

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

How To Nail Your eCommerce Replatform

Daniel Bergholz

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

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

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

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

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

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

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

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

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

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

### New Dev Server with HMR and HDR

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

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

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

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

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

### Native Support for PostCSS and Tailwind and PostCSS

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

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

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

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

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

### Server-Side Streaming with `defer`

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### Flat Routing by Default

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

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

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

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

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

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

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

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

## How to Upgrade Your Hydrogen Application to Remix v2

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

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

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

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

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

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

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

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

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

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

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

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

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

## What’s Next for Remix and Hydrogen?

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

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

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

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

What Does Remix v2 Mean for Shopify Hydrogen Developers?

Davide Di Stefano

In July this year, we [announced Sprout](https://nebulab.com/blog/announcing-sprout), our product gifting app.

Sprout allows brands to efficiently run product gifting campaigns without going crazy: rather than spending days buried in Instagram DMs and spreadsheets, brands can just connect their Shopify store, set up a gift link, and share it with the influencers they want to partner with. Influencers can use the link to select the product(s) they wish to receive and enter their shipping information, and an order appears in the brand’s Shopify dashboard, ready to be fulfilled by the brand’s team. It's as simple as that!

After beta testing our MVP with some customers for a few months, we got to work on our public launch. We had a pretty ambitious goal: we wanted to have a brand and website ready to go in just two weeks so we could start marketing the app to the general public.

In this article, we’ll show you how we met our deadline by following a strict design review process and using the right tools.


## Solid Branding Means Fast Execution

Branding is much more than having a good-looking, distinctive logo. For us, branding is about capturing the identity of a company or product, and then translating that into a visual foundation that can be used across the product’s properties. **A solid brand allows you to move quickly and confidently,** no matter what kind of digital or physical experience you’re working on, and it makes you immediately recognizable by prospective and existing customers.

As always, we started by defining a compelling positioning statement and researching Sprout’s target audience and competitors. Our goal in this phase is to understand what the brand stands for: is it a disruptor, fun and playful? Or is it the real deal, serious and professional? How does the brand relate to consumers? How does it relate to its competitors? Once we had defined and finalized all these elements, we began translating them into a visual identity.

For the visual identity, we vowed not to exceed three iterations–our goal was to have the final version ready in one week, and then move on to designing and implementing the website.

In our first round, we developed four brand directions, exploring different logos and mood boards representing various archetypes or styles.

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

This was super helpful in defining the visual communication we wanted to adopt, including the color palette and font combinations.

In the second round, we mixed and matched elements from the different proposals, settled on a logo and overall mood, and then started exploring different color palettes and font families.

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

In the final round, the work was nearly complete, and most of the decisions had been made. The rest was a matter of refining a few aspects of the color palette, typography, iconography, and overall visual style so that we could more easily reference them in our subsequent work.

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

At this point, we had established a brand identity and created a style guide to guide us while implementing the brand. We could finally focus on our website.

## Going From Figma to Finished Website in One Click

Figma has been our design tool of choice since its release, so it’s no surprise we also used it for Sprout. We created a quick landing page showcasing the product’s capabilities and most common use cases and allowing brands to request a demo. **Because we had defined the brand’s visual identity and UI fundamentals in advance, the original website design only underwent minimal modifications before being approved for publication.**

After finalizing the design in Figma, we typically hand it off to the engineers, who build it using whatever frontend stack has been adopted. This process leads to highly polished and sophisticated UIs but also takes more time as the engineers need to translate the designs into code and test and deploy the result.

With our two-week deadline, we needed a radically different approach: ideally, we wanted to go from Figma to the final website in one step. We also needed the ability to quickly make visual and content changes to the website after the initial publication to accommodate whatever feedback we received from existing and prospective customers.

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

We evaluated different [content management](https://nebulab.com/blog/ecommerce-content-management) options and ended up using [Framer](https://www.framer.com/). Here’s why:

* As long-time Figma users, the Framer UI feels very familiar, and the app is incredibly user-friendly.
* Framer allows importing Figma designs by simply copying and pasting the artwork, which is game-changing for a fast-moving team.
* The Publish feature is straightforward and blazing fast: we purchased a domain and were ready in minutes.
* Framer integrates with MailChimp, Formspark, and other tools that we use for marketing and lead generation, which further reduces development time.

After importing our designs into Framer, we only had to make a few adjustments to some elements, add some animations, hit Publish, and _voilà!_ Our website was online and available to the world in one week and with zero lines of code. Not only does it require zero maintenance, but anyone with access to the Framer project can easily make content and visual changes to the website.

Finally, we were impressed with the site's performance: even though we didn’t spend time optimizing it, it got top scores in all areas of Google’s PageSpeed Insights benchmarks–hooray for SEO!

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

## Use Guidelines and Constraints to Your Advantage

While an established work process improves your team’s long-term productivity, it can sometimes hinder your goals and even impede learning. Setting an arbitrary deadline forced our team to think outside the box and temporarily move away from our typical design-development handoff process. This allowed us to go from zero to a fully established brand and website in under two weeks. 

Of course, none of this would have been possible without a solid brand in place. By establishing a clear visual identity beforehand, we minimized the communication overhead while creating [Sprout’s website](https://getsprout.app), drastically improving our turnaround time.

We will probably re-implement Sprout’s website with a more sophisticated tech stack at some point, but for now, we’re thrilled with Framer’s ease of use and flexibility. In fact, next time we do something like this, we might even try designing the website right into Framer rather than going through Figma–who knows, we might be able to shave a couple more days off the timeline!

If you’re an e-commerce brand and would like to adopt a similar approach for your next landing page or product drop, feel free to [reach out!](https://nebulab.com/contact-us) We’d be happy to help.

How We Branded Our Latest Product in Just Two Weeks

Here’s a story you might have heard before: a brand has a dedicated design team, handling everything from packaging to ad creative to Web design. The design team works closely with the brand’s executive team, constantly asking for feedback and creative direction. Because designers work so closely with the executives, there’s no need to prioritize projects: people can just talk to each other and “figure it out.”

Then, as the brand starts scaling their Web development efforts, all hell breaks loose.

The brand’s development team starts complaining that the mockups they get from the designers are useless: they’re incomplete, contain visual bugs or inconsistencies, neglect to cover obvious error cases… the list goes on and on. On their side, the designers complain that the developers have no consideration for their work and constantly introduce discrepancies between the original mockups and the final implementation. In all of this, the executive team doesn’t know where the problem lies or how to fix it.

If this sounds familiar, it’s because it happens at least once, in some shape or form, to most e-commerce brands that invest a decent amount of time into their DTC store, not to mention brands that have mobile apps or other digital properties.

In the past, I faced this conundrum several times as I designed brand identities and digital experiences for brands across different sizes and industries. **When designers and developers don’t work well together, it slows down everyone’s work and kills team morale.** It’s the kind of technical problem that has a very tangible impact on a brand’s bottom line.

Luckily, there’s a better way to work. It’s an approach I found through a lot of trial and error, and I’m delighted to share it with you today. Through open communication and clear guidelines, you can create peace of mind for executives, designers, and developers peace of mind, increasing the velocity, scale, and quality of your digital team’s output.

Let’s see how exactly!

## The Myth of the Perfect Design Handoff

When I first tried to bridge the gap between designers and developers, I did what every detail-oriented person would do when tasked with a sufficiently complex problem: create a process. My thesis at the time was that if I _just_ included enough detail in my designs to remove even the smallest amount of guesswork, developers could just translate my mockups into code one pixel at a time, and we’d all live happily ever after.

So, I started doing just that: rather than treating every project as unique, I created a thorough process for prioritizing, executing, and delivering my designs. This included elements like annotations in the designs that clearly explained what the UI was supposed to do and in what way, error states, and even Loom recordings of me going through each screen in the flow and explaining it verbally. Every time a developer had a question that I forgot to cover, I made a note and refined my template, all in pursuit of The Perfect Design Handoff™.

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

There was only one problem with this process: **it didn’t work.**

It’s not that it didn’t help: being more detailed in my handoffs made life a bit easier for our development team–at the very least, we now all agreed on the bare minimum that should be included with every new user flow.

However, it didn’t really _solve_ the problem: no matter how detailed my annotations or how long my Looms were, developers still had questions about edge cases I forgot to cover, new components that needed to be implemented, and interactions between different user flows that I couldn’t possibly have foreseen.

Furthermore, after seeing the implemented designs, product managers often provided feedback that required design changes, forcing designers and developers to redo their work. With such a detailed handoff process, this required a lot of time and slowed down delivery.

I knew we needed to try something else, so I went back to the drawing board.

## The Only Path To Order Is Chaos

After deep thought, I realized I was trying to solve the wrong problem: my theory was that designers could single-handedly collect stakeholder requirements, work on them for a week or two, and turn them into pixel-perfect mockups that contained all the information developers needed for implementation. Developers would then use that information to implement a user flow that matched the mockup pixel by pixel.

That sounds very nice in theory, but it’s virtually impossible: product managers, designers, and developers approach projects from different angles and bring different perspectives. **These three stakeholders need to collaborate constantly and provide continuous feedback on each other’s work**–only then will the final product really satisfy their needs, not to mention the needs of the brand’s customers.

With this new collaborative spirit in mind, I worked with our product and development team to completely rearchitect how we delivered new features to our customers. Rather than aiming for the perfect handoff from stakeholders to designers and from designers to developers, we started investing much more heavily in open and constant communication:

* **We established a series of recurring calls** where every member of the team would present what we were working on, no matter whether it was a product requirements document, an initial mockup for a new feature, or a code-complete user flow.
* **We encouraged everyone to offer feedback** at any point in the process and worked hard to foster a sense of psychological safety on the team, so that no one would feel like their work was “under attack.”
* **We asked team members to coach each other** on their respective areas of expertise. Designers showed developers the basics of working with Figma, while developers taught designers about their implementation process.

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

We kept a light process in place to create consistency in how we worked together, but also empowered everyone on the team to contribute cross-functionally. This led to several situations in which a developer provided insightful feedback on how to handle an edge case, a product leader realized that a flow didn’t feel as smooth in the real world as it did in the mockups, or a designer spotted a visual bug while testing a developer’s work.

Most importantly, **it created a sensitivity and deep appreciation for the work done by our fellow team members**, making us better at our respective jobs: designers understood the importance of component-based design, developers became more mindful of visual discrepancies, and product leaders understood that design and implementation are never going to match perfectly.

The new process didn’t fix all our problems, but it did give us the tools we needed to address them together! **Internally, we called this approach Open Design.**


## Adopting Open Design for Your Brand

As I mentioned in the introduction, it’s not uncommon for an e-commerce brand to be stuck in a sense of constant chaos and urgency or to feel constrained by an overly structured handoff process.

The root cause of the problem often lies in the fact that brand founders are very visual people, and most of their design experience lies in branding, packaging, and product design. As a result, they approach design very rigidly and try to make everything perfect before it’s handed off to their development team for implementation. This approach then cascades to the rest of the team as the company grows.

Unfortunately, the same can be said for agencies: many e-commerce agencies are design-driven and treat development as an afterthought. This leads to a lot of friction in their internal workflows or how they collaborate with their clients or other agencies.

As much as we would like to give you detailed, step-by-step instructions for how you can break out of this jail and implement an open design process for your brand, there’s only one thing you need: **people who are willing and able to set their egos aside and work together.**

As a first step, we always recommend creating stable, recurring ceremonies for cross-functional team members to talk to each other and exchange feedback. We found that **once you establish that baseline for collaboration, people will re-orient themselves around the new way of doing things, and everything else will magically fall into place.**

But if you need any help adjusting your process or are looking for an agency that lives and breathes Open Design, [feel free to reach out](https://nebulab.com/contact-us)–we’d love to help!

The Nebulab