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

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

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

Let’s dive in!

## Creating Our Content Schema

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

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

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

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

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

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

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

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

This should be the end result:

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

All the files generated for Sanity Studio

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

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

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

export const schemaTypes = [banner]
```

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

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

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

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

## Connecting Hydrogen to Sanity

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

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

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

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

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

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

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

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

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

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

## Retrieving Content from Sanity

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

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

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

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

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

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

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

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

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

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

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

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

## Keep Up with The Ecosystem

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

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

How To Integrate Your Shopify Hydrogen Store with Sanity CMS

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

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

With unlimited digital estate, DTC brands can tell their stories, announce, entertain, educate, and keep their name front and center in customers’ minds, all of which is very hard to do in the limited shelf space afforded by wholesale partners. Now that even die-hard digitally-native brands are going omnichannel in pursuit of reach and profitability, **it’s paramount to double down on the exclusive capabilities of each channel to create complementary experiences—for DTC, content is one of the most obvious levers to pull**.

A slew of platforms has emerged over the past decade that promise to offer the definitive solution to all content management pains. These solutions provide functionality that covers the entire content management lifecycle, from writing to publishing, presentation, and SEO, but they do it in very different ways. In fact, we’ve seen at least four generations of content management tooling emerge in these years, all of which coexist today, serving different use cases and market segments.

For eCommerce operators, finding a North star to follow in this vastness can be tricky, and engineering teams are usually not much better off. If you haven’t been exposed to all these tools and understand the nuances of each, it’s easy to get lured in by the promise of unlimited flexibility and endless automation, only to find yourself stuck with a complex piece of software that requires weeks of integration work, or doesn’t play nice with your editorial workflow.

In this article, we will provide an overview of the content management space, as seen from the perspective of an eCommerce brand. You will learn the different types of tools you can use, their advantages and limitations, and some practical recommendations about which tool to adopt depending on your goal, use case, and growth stage. The goal is to equip you with all the knowledge you need to make an informed decision for your eCommerce brand.

## The four generations of content management

Different content management solutions have been launched in the last twenty years. While there’s no universal taxonomy, we can classify them under four categories: monolithic CMSs, headless CMSs, site builders, and page builders. In the following paragraphs, we’ll explore these different solutions, their pros and cons, and the leading players in each space.

### Monolithic CMSs

Monolithic CMSs were the first content management solution to emerge in the market. **These tools take over your entire content experience by handling every single aspect**: they provide an interface that allows you to edit and publish your content and present the content to your audience via a public-facing website.

You’ve probably heard about [WordPress](https://wordpress.org/), arguably the most popular CMS in the world. Initially built for blogging, WordPress has been expanded over the years to encompass an incredible number of use cases, allowing you to publish blogs, entire websites, and even online stores. It’s estimated that WordPress powers over 43% of all websites.

![WordPress website](https://cdn.sanity.io/images/kqgmf0g2/production/908b2d57d03ec193412387c8af8d151b6df2393b-2560x2136.png?fit=clip)

**Monolithic CMSs have been around for over fifteen years, and they’ve stood the test of time**. They offer a user-friendly, streamlined content editing experience and many plugins and apps that make them easy to repurpose for different use cases. Since they have a considerable market share, they also boast rich ecosystems of system integrators.

However, they also come with some limitations: th**ese content management systems are meant for content-centric websites, not for eCommerce brands.** They usually take over your entire website and don’t play nice with other parts of your tech stack. This makes them a less-than-ideal choice for a DTC brand, which needs to present the content on their storefront or even enrich it with dynamic data such as product information.

### Headless CMSs

Headless CMSs were built to solve precisely these limitations. **Compared to monolithic solutions, headless CMSs are much more nimble**: a headless CMS only provides an interface to define your content structure and manage your content. Presenting your content is up to you, and typically requires a design and engineering team to integrate the headless CMS into your existing frontend.

[Contentful](https://contentful.com/) has long been the primary contender in the headless CMS space, but many competitors have launched their solutions over the years: [Prismic](https://prismic.app/), [DatoCMS](https://datocms.com/), and [Sanity](https://sanity.io/) are among the most popular alternatives, offering slightly different functionality such as custom editorial workflows/UIs and internationalization, and wildly different price points.

![Contentful homepage](https://cdn.sanity.io/images/kqgmf0g2/production/551c31bc9b5a60be3f663151ba0172e06f790da5-2560x1810.png?fit=fill)

**Headless CMSs enable brands to treat content as data, making it fully portable and allowing them to present their content wherever they want**. Most headless CMSs also connect to your backend: for instance, an eCommerce brand will be able to pull product and pricing information from Shopify and include it right in the middle of an editorial piece. Such functionality allows you to blur the lines between content and commerce, making for a much richer customer experience.

Headless CMSs are still very popular thanks to their flexibility, but they come with their own limitations: mainly, **they require design and engineering work when marketers want to integrate new types of content into a company’s existing digital properties, or whenever they want to make visual changes to the existing experience**. This may be problematic for brands operating with low budgets or in high-velocity environments.

### Site builders

While site builders are not technically new (Webflow was born in 2012, one year before Contentful), they’ve seen a recent surge in popularity. You can think of site builders as a modern take on monolithic CMSs: like monolithic solutions, site builders also take over your entire website. However, **they offer more modern and advanced functionality**, such as support for drag-and-drop editing across your entire website, responsive design, custom code, API access, and integrations with popular third-party design and development tools. Almost all site builders also include a native headless CMS, or will optionally integrate with a third-party headless CMS.

The most popular site builder is [Webflow](https://webflow.com/), which is often used by SaaS companies to manage their marketing websites, or by eCommerce brands to spin up self-contained editorial experiences. Webflow also allows creating gated content and building Zapier-esque workflow automation. A recent competitor is [Framer](https://framer.com/), which allows designers to build, test and publish websites straight from Figma wireframes.

![Webflow homepage](https://cdn.sanity.io/images/kqgmf0g2/production/0082e34207f075b05269676c871a8d0d49b1601a-2560x2034.png?fit=fill)

**If your team has limited technical experience or you don’t want to use your engineering bandwidth, using a site builder can be an excellent way to quickly spin up new editorial experiences that will meet the standards of the modern Web.** And if you need to implement deeper customizations or complicated workflows, your engineers can still make those adjustments at a reasonable pace.

The main disadvantage with site builders is that, for all their flexibility, **they will still be pretty self-contained, and they’re hard to integrate with other digital properties.** Maintaining brand consistency will also be more challenging since your design system will live both in your site builder and across any other frontends you have. This is fine if you’re building a standalone experience such as a microsite, but can hurt your brand reputation when used for integrated experiences such as a company blog.

### Page builders

After coming full circle with site builders, the content management pendulum is swinging the other way once again with page builders. Like site builders, page builders also offer drag-and-drop editing, built-in headless CMSs, and all the modern developer tooling you might expect. **Unlike page builders, site builders try to be non-obtrusive: rather than taking over your entire website, they allow you to model specific pages or sections of it.** For example, you might let your eCommerce platform power your product catalog and checkout experience while your page builder powers your site navigation and blog.

The most popular page builder is [Builder.io](http://builder.io/), used by several eCommerce brands such as Everlane, J.Crew, and Harry’s. It allows you to use their native visual editor or to import your own components, connects with several third-party data sources, offers built-in A/B testing, and lets you publish your content across the Web, mobile, and wherever else you want. An early-stage contender is [Plasmic](https://plasmic.app/), which offers a very similar feature set, but pairs it with a more modern UX.

![Builder.io homepage](https://cdn.sanity.io/images/kqgmf0g2/production/29e681ed0cb541c8da8d8c65119b10cfe3f08b8d-2560x1528.png?fit=clip)

**Page builders can be an excellent compromise between headless CMSs and site builders**: they allow you to easily integrate your content into your existing digital properties in a non-obtrusive, brand-consistent way, and they offer a visual interface that helps non-technical stakeholders to quickly iterate on both content and presentation.

However, they are not a one-size-fits-all solution. **While an essential page builder integration can be a reasonably low-effort process for your engineering team, getting page builders right can be a complex initiative.** Once you start bringing in your own UI components, performing search engine optimization, running A/B tests, integrating with external data sources, or implementing rich user interactions, the level of complexity goes up dramatically, and keeping everything running smoothly can be a challenge.

## Evaluating the right solution for your brand

As you’ve seen, there’s no easy answer: each eCommerce CMS has its pros and cons, which you should weigh against your company’s stage, requirements, and technical savviness. The three main factors we keep into account when picking a solution for our clients are:

* **Business goals**: what do you want to achieve with your content? This is closely tied to where you’ll want to place your content, which in turn informs your choice of tooling. Are you looking to inform, inspire, or convert? (Often, it will be a mix of these, which is perfectly fine—just make sure you cover all your bases!)

* **Span of control**: site builders give operators maximum flexibility to change whatever they want, whenever they want it. This is both a blessing and a curse: a non-designer making design changes can quickly become a disaster. What’s the sweet spot between not enough and too much control for your team?

* **Implementation effort**: page builders are more complex to integrate than headless CMSs, which in turn are more complex to integrate than a monolithic CMS. Do the benefits outweigh the extra effort of integrating the solution with your tech stack?
Apparel brand and Nebulab client [Huckberry](https://huckberry.com/), for instance, relies heavily on their blog, [The Journal](https://huckberry.com/journal). The Journal is a fully integrated part of Huckberry’s shopping experiences: articles typically feature one or more Huckberry products, which users can add to their cart with a simple click. It’s a very conversion-centric approach.

![Huckberry’s blog, The Journal](https://cdn.sanity.io/images/kqgmf0g2/production/7ce46f90390f88961bbc568a2fafc78deb24b464-2560x2512.png?fit=clip)

Travel brand [Away](https://awaytravel.com/), on the other hand, publishes the travel and lifestyle magazine [Here](https://www.heremagazine.com/). Away’s magazine has a laid-back, inspirational approach with its content, and you can hardly notice that a DTC brand is behind the project.

![Away’s magazine, Here](https://cdn.sanity.io/images/kqgmf0g2/production/85383a0a4b600d7279c82359e0f0da9edf9209b8-2560x1664.png?fit=clip)

### Picking tools vs. building infrastructures

**Rather than only adopting one solution, we recommend creating a content management infrastructure, i.e., a suite of tools that integrate and build on top of each other.** For example, here’s a typical journey a DTC brand might undergo:

1. As a first step, they adopt a headless CMS, which allows them to decouple content and presentation. They use their headless CMS as the source of truth for all their content and integrate it with their existing digital properties (e.g., their product pages).

2. At some point, the marketing team starts complaining that they can’t make visual changes to how the content is presented on their product pages without asking the engineering team. This leads the team to integrate a page builder for specific website sections (e.g., the PDP and the blog). The page builder is connected to their headless CMS, which is still used for managing the actual content.

3. The brand eventually outgrows the page builder as well: the marketing team wants to start experimenting with standalone experiences such as microsites for contests, promotions, and product launches. This is when the team adopts a site builder, giving marketing full power to launch new properties with little to no engineering assistance.

**As marketing teams gain more freedom, brands need to create checks and balances to avoid brand dilution.** This can mean having a content inventory that is continuously monitored for consistency, ensuring the same person is orchestrating all digital experiences, or having a full-fledged design system that can be applied across different platforms. **Ultimately, how much centralization you need depends on your brand’s scale and your reliance on content.**

## Our favorite CMSs for eCommerce brands

At Nebulab, we have helped tens of brands design, launch and optimize their content stack, and we have developed some pretty strong opinions on which CMS platforms to use:

* **Monolithic CMS:** [WordPress](https://wordpress.org/). As mentioned, we rarely pick monolithic CMSs for eCommerce brands—but when we do, we go with WordPress. It has a beautiful, intuitive UX and an incredibly vast ecosystem of plugins and integrations, making it a good fit for many use cases and deployment options.

* **Headless CMS:** [Sanity](https://sanity.io/). A few years ago, we would have recommended Contentful or Prismic ([and we have](https://nebulab.com/blog/five-no-code-ecommerce-management-tools#the-best-headless-cms-prismic)). Ever since we’ve had a chance to try Sanity, we fell in love with its flexibility. While traditional headless CMSs force users to use a standardized UI for managing content, Sanity’s content studio is open-source and can be tailored to your content management needs and editorial workflows.

* **Page builder:** [Plasmic](https://plasmic.app/). While Builder.io has been around for slightly longer, Plasmic offers a more modern UI for their editing backend. With that said, the two tools are incredibly similar, so we encourage you to experiment with both and see which one you prefer.

* **Site builder:** [Webflow](https://webflow.com/). Even though products like Framer offer a more streamlined experience for non-technical users, Webflow remains an incredibly powerful tool if you know how to use it. With support for custom workflows and gated content, your team can quickly spin up rich micro-sites that cover various use cases.

As always, your mileage may vary. Before committing to a solution, you should thoroughly assess your present and anticipated requirements and experiment with different setups to build a stack that can scale with you as your needs evolve. If you need any advice or want to speed up the process, [we’re happy to help](https://nebulab.com/contact-us)!

Building Content Infrastructures for eCommerce Brands

As an eCommerce consulting firm, we know the value behind a custom store implementation: **not going
with a SaaS solution affords you maximum flexibility and endless innovation opportunities** —
there's nothing a good development team can't do.

For digital brands, this can be powerful: **when your platform doesn't limit you, you can implement
whatever you have in mind,** and create even stronger bonds with your customers.

However, there are also downsides:

* Having a solid development workflow is good for new features and invasive modifications, but it
  becomes a bottleneck when you only need to change an email template, or the arrangement of
  elements on a page. Relying on developers for these tasks can slow you down.
* **Your developers' time is important and, most likely, expensive.** Having them make trivial
  adjustments to your content or campaigns may not be the best use of their expertise. Instead, you
  should do whatever you can to free them up for more important work.

Luckily, a lot of tools have emerged over the last years that allow you to make changes to almost
every customer-facing aspect of your store without necessarily involving your developers. These are
SaaS tools that only have to be integrated with your store once, and then provide you with an admin
panel you can access and use autonomously.

There are a lot of options for different categories, and over the years we've used many of them for
our customers. Here's a round-up of the best one in each category, along with a few alternatives
you may also want to try!

## 1. Manage your content yourself

Content management is one of those areas where self-serve tools have been available for a long time,
but are not always used (the right way). Headless CMS solutions are all the rage now, and the
philosophy behind them is fairly simple.

Unlike a traditional CMS, that allows editors to enter whatever they want in the page, with the risk
of creating un-optimized or even broken layouts, **headless CMSs require your developers to specify
the possible structure of the content upfront.** Content editors can then manage the content through
the headless CMS. Finally, this content is pulled by your store and displayed to your customers when
they visit the corresponding page(s).

While they may seem limiting to someone accustomed to old-style content management tools, **headless
CMSs are extremely powerful if used the right way**, and they can be just as flexible, if not more,
than traditional solutions, while sparing your developers a lot of tedious work.

### The best headless CMS: Prismic

[VIDEO](https://drive.google.com/file/d/181Oppz0QeRmrr11ShCrQ4DXC4jwpTNQT/view?usp=share_link)

Out of all the headless CMSs we have tried, [Prismic](https://prismic.io) definitely comes out on
top. **It's an extremely modern tool with a powerful API and development toolkits for the most
popular languages, and it can be easily integrated in any application.**

Its pricing is also [very competitive](https://prismic.io/pricing), with a free basic plan and
attractive options for organizations of all shapes and sizes.

There are a couple of alternatives also worth considering:

* [Alchemy CMS](https://alchemy-cms.com/about) is an open-source, self-hosted headless CMS for Ruby
  on Rails applications. It's a good option if you don't want to pay a third-party to host your
  content, but may be more complex for your development team to configure and maintain, especially
  if they don't have experience with Ruby.
* [Contentful](https://www.contentful.com) is Prismic's main competitor. While it's a solid option
  trusted by large companies such as Spotify, Lyft and Twilio, we have found it to be less reliable
  than Prismic, and a bit behind the curve when it comes to its technical capabilities. The pricing
  is also [much steeper](https://www.contentful.com/pricing) than Prismic's, going from $39/mo to
  $879/mo.

## 2. Build 360-degree marketing campaigns

**For digital brands, creating a loyal customer-base that identifies with your values and mission is
a matter of life or death**, and how, when and where you communicate with your users is key to
creating a successful and engaged community of brand _aficionados_.

Unfortunately, very often these touchpoints are hardcoded by developers into the application, which
means every experiment and every change need to go through the development team before customers can
benefit from them. **This can be especially critical for time-sensitive marketing campaigns,** where
getting the timing right can mean the difference between a customer and a lost sale.

Luckily, there are a few tools out there that can help you take back control. The integration flow
is usually straightforward: you ask your developers to send customer information to the marketing
automation service, which you then use to communicate with customers autonomously.

### The best marketing tool: Klaviyo

![The Klaviyo email marketing UI.](https://cdn.sanity.io/images/kqgmf0g2/production/34c56d7e6b8d6bda3f2dfaf44a6668137211eab0-1395x762.png?fit=clip)

A relatively recent product, [Klaviyo](https://www.klaviyo.com/) won our hearts when we first used
it, thanks to its flexibility and ease of customization for the end-user.

It allows you to run email, SMS and social media marketing campaigns all from the same interface
and leveraging the same dataset, and (obviously) supports A/B testing of your campaigns so that you
can test small changes and tweak your campaigns accordingly.

But where Klaviyo really shines is in its event-based architecture: by integrating with your store,
**Klaviyo knows when your customers take certain actions and allows you to build complex automated
campaigns** such as abandoned cart flows, all without having to involve your devs!

The most prominent alternative to Klaviyo is [Mailchimp](https://mailchimp.com), a giant in this
industry. While it provides many of Klaviyo's features, Mailchimp lacks SMS marketing capabilities
and has other features, such as landing pages and postcards, that may not be needed by the average
brand.

## 3. A/B test to your heart's desire

A/B testing can be a complex feat to pull off properly. Not only do you have to implement the
testing logic, but you also need a solid framework in place to validate the results of your
experiments and ensure you're not jumping to conclusions.

From a technical standpoint, implementing experiments is not fun either: each experiment needs to
be implemented manually, and failed experiments often linger unused in your codebase because no one
has time to remove them. **Over time, this accumulation of failed experiments can create huge
amounts of technical debt and slow down development.**

The complexity behind running a reliable A/B test often puts off companies who'd like to start with
the technique. When done right though, **A/B testing can be a powerful tool to optimize your
conversion rates and get a better sense of your customers' taste**, and there are a few tools you
can use to make this process a breeze.

### The best A/B testing tool: Optimizely

![The Optimizely A/B testing UI.](https://cdn.sanity.io/images/kqgmf0g2/production/1c7ac7dc278e63f43c8fd68b6f1cf66dd6f6101b-1849x1278.png?fit=clip)

[Optimizely](https://www.optimizely.com/) is an all-in-one platform for A/B testing all aspects of
your website, trusted by the most prominent startups and enterprises. A full-stack implementation
consists of two components:

* A frontend plugin that allows you to **run customer-facing A/B tests without involving your
  development team**, e.g. testing two versions of your landing page.
* A backend integration that allows your development team to implement A/B tests for more complex
  aspects, such as testing different promotions or shipping options.

You can manage experiments directly from Optimizely's UI, **which will also determine the winner
with its proprietary algorithms** — no Excel spreadsheet needed.

A popular alternative to Optimizely is [LaunchDarkly](https://launchdarkly.com), although you should
know LaunchDarkly is more focused on feature flags and does not provide a visual editor that allows
you to run customer-facing experiments without asking your developers.

## 4. Up your data collection game

Data is the stepping stone in the journey from online store to digitally-native vertical brand. As
Andy Dunn, one of Bonobos' co-founders and
[the man who coined the term _DNVB_](https://medium.com/@dunn/digitally-native-vertical-brands-b26a26f2cf83),
says:

> Deeper data on the consumer drives enables the DNVB to stay closer to the customer than its brick
> and mortar driven peers, and the ownership of the brand end-to-end fuels more affinity for a
> vertical commerce brand than even the best e-commerce experiences.
Being able to do more with your data unlocks new possibilities for your business. In turn, **your
ability to analyze data in a meaningful way is a function of how much data you collect and where.**

Traditionally, adding a new analytics service to your toolbelt has been very dependent on
development work. Developers would have to write a custom integration for the new service and then
test it to make sure data was being collected consistently and reliably. This could result in slow
integration times and lost opportunities.

But in the last few years, a new category tools was born that promise to solve this problem once
and for all. This new breed of services acts as a gateway between your application and all of your
tracking and analytics tools. They provides a unified programming interface that **drastically
simplifies the integration work for your development team,** as they only have to integrate with one
service and not ten. Store owners can then manage all of their tracking integrations from the
gateway's control panel. Adding new services is as simple as clicking a button — no dev needed!

### The best data platform: Segment

![The Segment data collection UI.](https://cdn.sanity.io/images/kqgmf0g2/production/0f94ab549ae2c13cf121a0c26936e899aa9f079d-1121x519.svg?fit=clip)

[Segment](https://segment.com) touts itself as a customer data platform (CDP). In other words, they
provide a centralized data collection service and give you the tools you need to manage and act on
your data.

Trusted by tens of startups and large organizations, Segment lives up to its promise of dramatically
simplifying data collection: **developers only have to integrate Segment in your application once.**
You can then enable and test new tracking and analytics services in a blink of an eye, freeing up
your engineering team's time for other initiatives.

In our experience, **Segment is incredibly reliable and provides an amazing user experience.** It
reduces development spend and implementation time.

A popular alternative is [Google Tag Manager](https://tagmanager.google.com/), which allows you to
manage all of your tracking snippets from one interface. However, GTM is much more limited than
Segment, because it simply acts as a central repository for different tracking codes, and doesn't
know anything about the data you are collecting. On the upside, it's free, so it may be a good
starting point if you just want to dip your toes in this water, or if you don't need a full-fledged
data collection platform.

## 5. ...and access new business insights!

Now that customer data is flowing in the right direction(s), it's time to use it to make informed
decisions about your business. In order to do that, many stores develop their internal reporting
tools, which take a lot of time away from core business priorities, or turn to Excel spreadsheets,
which often fall short of business requirements.

Instead, **companies that use data to drive important decisions, such as digitally-native vertical
brands, can and should rely on battle-tested Business Intelligence (BI) platforms.** These are tools
that plug directly into your data sources and can generate reports about all aspects of your
company's operations and sales.

Using a BI platform instead of in-house solutions allows you to access richer insights into your
data and let your developers focusing on core business capabilities rather than internal software.

### The best BI platform: Looker

![The Looker business intelligence UI.](https://cdn.sanity.io/images/kqgmf0g2/production/ad302d86b3f6a04f0641560e3f0bcdc04966649d-942x571.png?fit=clip)

There's no shortage of BI platforms, as these tools have always been used by companies of all sizes
to better understand the market and drive strategic decisions. Among all the options,
[Looker](https://looker.com) stands apart for its modern take on business intelligence.

By combining BI, data visualization and reporting capabilities, **Looker allows you to create very
flexible experiences:** for instance, you can embed data visualizations directly in your store's
dashboard, or send a sales report every month to your key decision-makers, so that everyone's always
in the loop and can make the right decisions.

**Looker allows you to access the data you need, wherever you need it,** making sure that reports
are being put to good use rather than just sitting there and gathering dust.

[Tableau](https://www.tableau.com) is also worth looking into, although it takes a more traditional
approach to business intelligence, centralizing all your data and reports under the same roof.

## Flexibility + automation FTW

Most of these tools have plugins to integrate with the most popular SaaS eCommerce platforms.
Unfortunately, **these plugins often offer a shallow integration** that doesn't cover all customer
touchpoints or doesn't capture all the data you could leverage.

In some cases, the fault lies on the plugin developer for not doing a good job. In others, it's due
to the sandboxed nature of SaaS solutions, that don't expose all the hooks and information the
services need to show their full potential.

**By adopting a flexible, open-source eCommerce framework such as [Solidus](https://solidus.io), you
are getting the best of both worlds:** on one hand, you can create deep integrations that let you
leverage all the features of these awesome services; on the other, you are not limited by your
platform, and can implement all those features that make your brand stand apart from its
competitors.

5 No-Code eCommerce Management Tools

Like all web developers, I love to experiment with new tools, libraries and frameworks.

This time, for one of my side projects (my new portfolio), I decided to use [NuxtJS](https://nuxtjs.org/), which is a framework built on top of VueJS that allows to build SPAs and static websites blazingly fast, and [Prismic](https://prismic.io/), which is a Cloud headless CMS.

I've been using WordPress for years, but recently I've started working with VueJS and Nuxt on other projects, and not much time passed before deciding to build my new portfolio with Nuxt, mostly because of VueJS' ease of use.

But having a static website means that whenever I want to update it I have to:

- Open my code editor
- Make all the changes needed
- Commit to my repository
- Upload the updated/new files to the server

Not the ideal situation to be honest; I wanted to have a static website but manage its content without writing code, this is why I decided to add Prismic to the project.

By using Prismic, I can have a static website that fetches its content from an API; sounds perfect!

But there's a downside: whenever I add new content (a blog post or a case study), I still have to add the new content's page to the site's source code, meaning I'm back at the starting point.

The solution is quite simple: during the generation of the site, I tell Nuxt to make calls to the Prismic API and dynamically create those pages.<br>
Doing so, I don't have to write a single line of code anymore, bingo!

But I wanted to push it a bit further because it's true that this mechanism works, but every time a page is visited it makes a call to the Prismic API to fetch the content; this is pretty useless, and on a large scale website it can become costly.

I mean that I wanted to make those API calls only when generating the website, creating a completely static website, and at the same time having a CMS to manage its content.

> "But how do I regenerate the website everytime I update the content?"

The website is hosted on [Netlify](https://www.netlify.com/) and I've configured a webhook that whenever is triggered by Prismic it regenerates the whole website.

It's really easy to configure:

- [Create an incoming webhook on Netlify](https://www.netlify.com/docs/webhooks/#incoming-webhooks)
- [Configure webhooks on Prismic](https://user-guides.prismic.io/webhooks/webhooks)

## TL;DR;

You can find the code in [this GitHub repository](https://github.com/kekkorider/nuxt-prismic-app).

There's also a [demo available](https://determined-panini-7baf61.netlify.com/).

### 01. Creating the NuxtJS app

[Creating a new NuxtJS application](https://nuxtjs.org/guide/installation#using-code-create-nuxt-app-code) is pretty straightforward, all you have to do is open your terminal and launch

```
yarn create nuxt-app <my-project>
```

At this point, `nuxt-create-app` asks a couple of questions like the project's name, description, server, UI framework to use and so on

![create nuxt app command](https://cdn.sanity.io/images/kqgmf0g2/production/af880aca6b4ee5b59f337269f484bb799c506e21-1378x1162.png?fit=clip)

The next step is to `cd` into the project's folder and run

```
yarn run dev
```

and voilà, the new application is running at `http://localhost:3000/`.

![nuxt app created](https://cdn.sanity.io/images/kqgmf0g2/production/708e9deec984925fd5b91f6bb498f74cd4e1e411-1309x777.png?fit=clip)

## 02. Creating the Prismic backend

The website will be quite standard: it will have a homepage, an about page, a list of posts and an X amount of single post pages.

Let's start by [logging in into our Prismic account](https://prismic.io/dashboard) and create a new repository with three content types:

- Homepage (single type)
- About page (single type)
- Blog post (repeatable type)

### Important note

When creating the `Blog Post` content type, make sure you set up a `UID` field, it will be the slug of each post.

Noticed that I haven't set up a "Posts index" custom type? That's because I'll setup Nuxt to create that page when generating the website.

With the content types created, the custom types list will look like this

![prismic custom types list](https://cdn.sanity.io/images/kqgmf0g2/production/0b783ae71d8acfd1e8ef1a80812ba000b3d670b0-1189x634.png?fit=clip)

Now, let's fill in some content in the **Content** section

![prismic content created](https://cdn.sanity.io/images/kqgmf0g2/production/db99fbc5dd003154187e4af8409664c014ddd44c-1230x675.png?fit=clip)

## 03. Set up Nuxt to retrieve content from Prismic

The first thing to do is to add the `prismic-javascript` and `prismic-dom` modules, which are the two libraries that allow to query and parse content from Prismic.

Install `prismic-javascript` and `prismic-dom` by running

```
yarn add prismic-javascript prismic-dom
```

and then create a `prismic-config.js` file at the root of the project with the following content:

```javascript
// prismic.config.js
import Prismic from 'prismic-javascript'
import PrismicDOM from 'prismic-dom'
const config = {
  baseUrl: '<API_ENDPOINT>',
  access_token: '<ACCESS_TOKEN>'
}
export const initApi = req => {
  return Prismic.getApi(config.baseUrl, {
    accessToken: config.access_token,
    req: req
  })
}
export const linkResolver = doc => {
  if (doc.type === 'blog_post') return `/blog/${doc.uid}`
  return `/${doc.uid}`
}
export const generatePageData = (documentType, data) => {
  switch (documentType) {
    case 'homepage':
      return {
        title: PrismicDOM.RichText.asText(data.title),
        content: PrismicDOM.RichText.asText(data.content)
      }
    case 'about_page':
      return {
        title: PrismicDOM.RichText.asText(data.title),
        content: PrismicDOM.RichText.asText(data.content)
      }
    case 'blog_page':
      return {
        posts: data
      }
    case 'blog_post':
      return {
        title: PrismicDOM.RichText.asText(data.title),
        content: PrismicDOM.RichText.asText(data.content)
      }
  }
}
```

This file contains the Prismic's configuration and a couple of functions that are used in every template to initialize the APIs (`initApi`) and generate each page's content (`generatePageData`)

The Prismic `API_ENDPOINT` can be found in `Settings -> API & Security -> API Endpoint`.

An `ACCESS_TOKEN` is required only if the backend is set as `Private` in `Settings -> API & Security -> Repository security`

Now, open the `nuxt.config.js` file and add the following code:

```javascript
// nuxt.config.js
const Prismic = require('prismic-javascript')
import { initApi } from './prismic.config'
module.exports = {
  ...
  generate: {
    routes: function() {
      // Fetch content for the homepage and generate it
      const homepage = initApi().then(api => {
        return api
          .query(Prismic.Predicates.at('document.type', 'homepage'))
          .then(response => {
            return response.results.map(payload => {
              return {
                route: '/',
                payload
              }
            })
          })
      })
      // Fetch content for the about page and generate it
      const aboutPage = initApi().then(api => {
        return api
          .query(Prismic.Predicates.at('document.type', 'about_page'))
          .then(response => {
            return response.results.map(payload => {
              return {
                route: '/',
                payload
              }
            })
          })
      })
      // Fetch all the blog posts to generate the Blog page
      const blogPage = initApi().then(api => {
        return api
          .query(Prismic.Predicates.at('document.type', 'blog_post'))
          .then(response => {
            return [{
              route: `/blog`,
              payload: response.results
            }]
          })
      })
      // Fetch again all the blog posts, but this time generating each post's page
      const blogPosts = initApi().then(api => {
        return api
          .query(Prismic.Predicates.at('document.type', 'blog_post'))
          .then(response => {
            return response.results.map(payload => {
              return {
                route: `/blog/${payload.uid}`,
                payload
              }
            })
          })
      })
      // Here I return an array of the results of each promise using the spread operator.
      // It will be passed to each page as the `payload` property of the `context` object,
      // which is used to generate the markup of the page.
      return Promise.all([homepage, aboutPage, blogPage, blogPosts]).then(values => {
        return [...values[0], ...values[1], ...values[2], ...values[3]]
      })
    }
  },
  ...
}
```

What the code above does is pretty simple: it queries all of our custom types (`homepage`, `about_page` and `blog_post`) from Prismic and passes the data to our templates.

## 04. Create templates and components

I'll try to explain all of these templates and components, but you can just copy-paste them in their respective locations.

```html


<template>
  <nav class="nav">
    <nuxt-link to="/">Logo goes here</nuxt-link>
    <ul class="nav-links">
      <li class="nav-link"><nuxt-link to="/">Homepage</nuxt-link></li>
      <li class="nav-link"><nuxt-link to="/about">About</nuxt-link></li>
      <li class="nav-link"><nuxt-link to="/blog">Blog</nuxt-link></li>
    </ul>
  </nav>
</template>

<style scoped>
.nav {
  align-items: center;
  display: flex;
  justify-content: space-between;
  padding: 20px;
}
.nav-links {
  list-style-type: none;
  margin: 0;
  padding: 0;
}
.nav-link {
  display: inline-block;
  margin-left: 20px;
}
</style>
```

☝ The navigation top bar

```html


<template>
  <div>
    <main-nav/>
    <nuxt/>
  </div>
</template>

<script>
import MainNav from '@/components/MainNav.vue'
export default {
  components: {
    MainNav
  }
}
</script>


<style>
html {
  font-family: 'Source Sans Pro', -apple-system, BlinkMacSystemFont, 'Segoe UI',
    Roboto, 'Helvetica Neue', Arial, sans-serif;
  font-size: 16px;
  word-spacing: 1px;
  -ms-text-size-adjust: 100%;
  -webkit-text-size-adjust: 100%;
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: antialiased;
  box-sizing: border-box;
}
body {
  background-color: #fafafa;
  margin: 0;
}
a {
  text-decoration: none;
  color: #5CBEFD;
}
*,
*:before,
*:after {
  box-sizing: border-box;
}
</style>
```
☝ The default layout with common styles

```html


<template>
  <section class="container">
    <h1>{{ "{{" }} title }}</h1>
    <div>{{ "{{" }} content }}</div>
  </section>
</template>

<script>
import Prismic from 'prismic-javascript'
import { initApi, generatePageData } from '@/prismic.config'
export default {
  asyncData(context) {
    if (context.payload) {
      return generatePageData('homepage', context.payload.data)
    } else {
      return initApi().then(api => {
        return api
          .query(Prismic.Predicates.at('document.type', 'homepage'))
          .then(response => {
            return generatePageData('homepage', response.results[0].data)
          })
      })
    }
  }
}
</script>
```
☝ Our homepage.

As you can see, I've set up an `asyncData()` method. This method is [part of NuxtJS](https://nuxtjs.org/api/) and is responsible for fetching the data before rendering the page.

Inside of `asyncData()` I check if the `context` object has the `payload` property (if the `yarn generate` script is running).

If so, we directly return the data using the `generatePageData()` function I created in `prismic.config.js`.

But the `payload` is only available when I'm generating the site using `yarn generate`, during development `payload` doesn't exist, so we have to fetch our data from Prismic first and then return the data with `generatePageData()`.

```html


<template>
  <section class="container">
    <h1>{{ "{{" }} title }}</h1>
    <div>{{ "{{" }} content }}</div>
  </section>
</template>

<script>
import Prismic from 'prismic-javascript'
import { initApi, generatePageData } from '@/prismic.config'
export default {
  asyncData(context) {
    if (context.payload) {
      return generatePageData('about_page', context.payload.data)
    } else {
      return initApi().then(api => {
        return api
          .query(Prismic.Predicates.at('document.type', 'about_page'))
          .then(response => {
            return generatePageData('homepage', response.results[0].data)
          })
      })
    }
  }
}
</script>
```
☝ The About page, same as the homepage

```html
// pages/blog/index.vue

<template>
  <div class="container">
    <h1>Blog page</h1>
    <hr>
    <article class="post" v-for="(post, index) in posts" :key="index">
      <header>
        <h1>
          <nuxt-link :to="`/blog/${post.uid}`">{{ "{{" }} "{{ "{{" }}" }} Dom.RichText.asText(post.data.title) }}</nuxt-link>
        </h1>
      </header>
    </article>
  </div>
</template>

<script>
import Prismic from 'prismic-javascript'
import PrismicDOM from 'prismic-dom'
import { initApi, generatePageData } from '@/prismic.config'
export default {
  data() {
    return {
      Dom: PrismicDOM
    }
  },
  asyncData(context) {
    if (context.payload) {
      return generatePageData('blog_page', context.payload)
    } else {
      return initApi().then(api => {
        return api
          .query(Prismic.Predicates.at('document.type', 'blog_post'))
          .then(response => {
            return generatePageData('blog_page', response.results)
          })
      })
    }
  }
}
</script>
```
☝ The blog page.

Here, the code inside the `asyncData()` method is a bit different from the one of Homepage or the About page; that's because there's an **array of contents**.

The difference here is that we do not pass the `data` property of the `payload` to `generatePageData()`, but directly the `payload`.

Also, we include the `PrismicDOM` library to the component's `data`, so that we can use it to print all our contents into the template by writing

```javascript
Dom.RichText.asText(post.data.title)
```

where needed.

(Yes, I _could_ avoid using the `PrismicDOM` library, but in that case we have to write something like `post.data.title[0].text[0]`)

```html


<template>
  <div class="container">
    <h1>{{ "{{" }} title }}</h1>
    <div>{{ "{{" }} content }}</div>
  </div>
</template>

<script>
import Prismic from 'prismic-javascript'
import { initApi, generatePageData } from '@/prismic.config'
export default {
  asyncData(context) {
    if (context.payload) {
      return generatePageData('blog_post', context.payload.data)
    } else {
      return initApi().then(api => {
        return api
          .query(Prismic.Predicates.at('my.blog_post.uid', context.params.slug))
          .then(response => {
            return generatePageData('blog_post', response.results[0].data)
          })
      })
    }
  }
}
</script>
```
☝ The single post template

First of all, did you notice the file structure? The folder's name starts with an underscore, that means that its name will be auto-generated via our configuration in `nuxt.config.js`.

For our single posts we wrote

```javascript
route: `/blog/${payload.uid}`
```

This means that `_slug` will be replaced with the `UID` of our post, resulting in a tree that will look like this:

```
/root
  /blog
    /post-01
      index.html
    /post-02
      index.html
    /post-03
      index-html
```

## Conclusion

You did it, you've managed to create a NuxtJS website that fetches its content only during the build process (except for development of course).

This allows you to save a lot of bandwidth (and also money) because it only calls the APIs once per content type instead of every page load. Cool uh?

I hope you found this post useful, if you have questions, found a bug or just want say hi, leave a comment.

The Nebulab

How To Integrate Your Shopify Hydrogen Store with Sanity CMS

How to Build Your eCommerce Tech Stack

How We Branded Our Latest Product in Just Two Weeks

Building Content Infrastructures for eCommerce Brands

5 No-Code eCommerce Management Tools

Creating a Blazing-Fast Nuxt.js Website with Prismic