Platforms like Shopify have made it possible for entrepreneurs to quickly get storefronts up and running, and its attitude of embracing developer partners has created an equally important ecosystem of infrastructure entrepreneurs to support merchants.
With scale, merchants demand higher levels of flexibility and control, and the impact of speed on conversion is more pronounced. Enter headless architecture, which allows merchants to decouple the front-end storefront from the back-end. On this podcast, we’ll discuss the implications of adopting headless, when merchants should & shouldn’t consider going headless, and ripple effects to the rest of the ecommerce ecosystem.
For this episode, Mike sat down with Steve Sewell, co-founder and CEO of Builder.io, who provides a commerce-oriented headless CMS with full drag & drop no-code editing, and Jordan Gal, founder of CartHook, who builds checkout optimization and post-purchase upsell software for Shopify stores. This is the first episode in Greymatter’s capsule series on commerce infrastructure, hosted by Mike Duboe.
You can listen to the podcast here:
Full Episode Transcript
Mike Duboe: I’m Mike Duboe, a partner at Greylock. Welcome to our podcast, Greymatter, where we bring in some of today’s top entrepreneurs and business leaders to share their stories from startup to scale up.
Today, we’re talking with Steve Sewell, co-founder of Builder.io, a no-code commerce page and experience builder, and Jordan Gal, founder at CartHook, one of the most well-known (potentially controversial) Shopify apps. Great to have you here, guys. Thanks for having us.
Steve Sewell: Thanks for having us.
Jordan Gal: Thank you. Thanks for having us on.
Mike Duboe: All right. So at Greylock, we’ve been spending a lot of time looking at the software and infrastructure layer around commerce. These two have just super valuable perspectives around the very timely, potentially misunderstood topic of headless commerce. And so that’s what we wanted to dig into today and kind of get tactical with. There’s a lot of ground to cover before jumping in. Let’s spend some quick time on your background.
So, Steve.You’ve been working on Builder for some time. Now the product just recently launched the wild. Tell us a little bit about your journey and what Builder is today.
Steve Sewell: Yeah, of course. So back in about 2014, I joined a company ShopStyle.com. It was actually an acquisition from a startup that my co-founder and I were doing prior, and they had an amazing product. They searched basically a whole huge list of merchants and allow you to sort of filter through and find great products to buy. But when I joined to run their web engineering team, I quickly found they had a very, very data-tech stack, which meant a very slow site. And it was very hard to work with. It’s very hard to optimize the site, build any new contents, anything that you’d want a good e-commerce business to do.
I had been previously working on this new Jamstack technology, a new way of making faster sites that feel more like native apps, especially can help you on mobile and they especially can help with conversions. And so when I joined, you know, I’ve been working on this open source technology for a while, so my first thought was “We need to re-platform. We need to get onto a new front end and we need to make the site better – to build new things better, to optimize better, and to have a better experience for the end users.” And so my first thought was to get on this tech stack. But the thing was, this was new to that company, and so I had to really sell it within the organization. But I was able to get that across by building a proof of concept and actually showed a new, faster Shopstyle.com site. We got the whole organization on board and released the new site in 2015. And we made a lot of groundbreaking technology updates, we contributed to open source, we developed a new technology. We open-sourced new code and new frameworks, and that was all awesome until we hit a really critical problem, which was around tooling.
We had this amazing new front end, this amazing new mobile and desktop experience. But the problem, though, was if marketing or anyone in the business wanted to make any change to the website – optimize a page, create a new page, or, really, just manage anything – there were basically no options. The only option was to wait for developers to do it, and developers have their own problems. You’re going to go into a backlog, and they’re going to get to it when they can. That made it so the business was not able to move quickly. [It was not able] to actually innovate and to actually run tests to find out what would make their product better, convert and sell more and all that good stuff. And it just became overwhelmingly obvious something new was needed. We tried a few options. Everything was either kind of only suited for the old generation, which would really just slow the site down again, or cause problems for this new type of technology.
And so it became obvious to me that something new was needed here, but it was unclear. You know, one of the challenges of headless is there’s a lot of technology options. So I left my job. I was kind of bored with it at the point anyway and said, well, I’ll find out, you know, I’ll start building something. I’ll see if it actually makes sense and put something together. I got ShopStyle as our first customer, and it was great to see that it was enough of a hair-on-fire problem for them to want to jump on board and try it out. Then I quickly worked with their team to make sure it met all their needs, and continued to work and discover more customers with the same problem. This is definitely not a ShopStyle problem. This is a broader e-commerce problem: people needing faster sites with better, more native app-feeling user experiences. I started acquiring quite a bit more customers and released a Shopify app just this year to plug in there and help people manage that experience and bring that experience headless. And that kind of leads to where we are today.
Mike Duboe: Awesome. There’s a bunch of points I want to dig into there. And before doing so, Jordan, let’s do your intro. So you’ve been in the e-commerce infrastructure world for the past seven or eight years and you were pretty early to the Shopify ecosystem. Just tell us a little bit about your journey.
Jordan Gal: I started in e-commerce running my own e-commerce company. We were looking at CSN Stores and NetShops were doing – those two would become Hayneedle and Wayfair. And the way they started was hundreds of very, very niche sites. They were basically doing Google AdWords arbitrage in a similar way to what a lot of merchants are doing now with Facebook arbitrage. And so we started copying them and looking at where they were spending their advertising dollars. And that was my e-commerce business. And I was the one responsible for conversion rate optimization. And I got obsessed with optimizing the funnel and I got obsessed with optimizing our checkout process, which sounds familiar now – it makes sense on what we’re doing now. After selling that business, I looked at the list of expenses that we had on a monthly basis and identified an abandoned cart app as having a ratio that was out of whack in terms of how much we spent and how much we got back from it.
We’d be paying 80 bucks in a month that we’d do four or $5,000 bucks a month in revenue from. But the product was terrible. So I just built a better version of that along with a few other people (I’m not technical). The reason it’s called CartHook is because the company started in 2015 with an abandoned cart app, and that’s what got us into the e-commerce world. We built a bunch of integrations and, actually, we integrated with Shopify last because their checkout doesn’t allow JavaScript onto it. Our magic was grabbing the email as soon as it was typed on the page, so when going over to Shopify, we’d lose the magic. We didn’t want to do it until the demand became overwhelming; where people just kept asking, “Well, when are you going to integrate with Shopify?” In that process of integration is when we came across the Shopify checkout and how rigid it is. That’s actually what led to the idea to build a checkout product.
So, all of this stuff kind of cascades back from one experience to the next, to the next, and then CartHook (where it is today) turned into a checkout app that allowed people to customize their checkout and add post-purchase upsells. And we just transitioned out of that and into a supported app that works with native Shopify checkout.
Mike Duboe: Yeah. And it’s a fascinating background and there’s a lot that resonates. Just to put this into context, I was reading a stat recently that over four and a half trillion dollars is left in e-commerce carts every year. I think that’s just in the U.S. And over 80% of mobile shopping carts are abandoned, so it’s a huge problem – the problem of cart abandonment – but also conversion optimization. This moves into the topic around “headless”. Over the past year, the term has really started to enter the ether brands, agencies, and developers. It’s all a term that everyone’s talking about. You two have been in the e-commerce world for a while, so you have perspective on headless before it became popular. Steve, I want to revisit some of what you were saying in your intro. Can you define what “headless” means and why it might be important?
Steve Sewell: Of course. So, “headless” basically means separating your front end from your backend. So, obviously what is a front end and what is a backend? The front end is what your customers actually experience on your storefront on your site when they’re swiping and tapping pages and content. The backend is where your data is stored. So for an e-commerce site, that’s your products,SKUs, quantities, prices. All of the stuff you’re managing in Shopify is admin. Back in the day – like in the days of WordPress – those two things were basically one thing in the technology stack. It was one box serving this content, and it really wasn’t the best of either world, necessarily. In the last five to 10 years, there’s been a lot of innovation, probably driven by the amazing benefits and the proliferation of mobile devices that we need. Something that feels more like a native app in your browser, that can load instantly just like any website and not make you wait and not feel jarring but feel like a native app once it’s loaded. And the prior technology just doesn’t work the way. A server served pages, and tapping anything back to the server just refreshed all the content. It just wasn’t right. So back in the day, like in 2015, we were kind of on the fringe for experimenting with this. And today it’s much, much more evolved.
So now, going headless means separating the front end and back end. So the front end is your head, the back end in this metaphor is your body. And being able to unlock from yesterday’s technology and move into having new technology options for your front ends unlocks the ability to build a much faster site, which we know has a lot to do with conversions. And it’s one of the biggest factors in getting conversions. Tragically, speed is a good way to lose conversions. People want to buy, but your experience is so bad that they just abandon your site. They just leave. But at the same time, so many more people are shopping on their mobile device and are now kind of glued to their mobile device in general. You know, it’s something we need to really take seriously.
Mike Duboe: Yeah. I think a lot of people simplify and really distill down the benefits of going headless is just site speed. One of the other angles that we’ve discussed is run portability: having more flexibility on what your backend is and being able to port over your storefront to a new environment without having to rebuild the entire thing. Something that, candidly, I’ve reflected on as it pertains to that, is this: Is betting on headless the same as going and betting against Shopify? Because it feels like many people building around e-commerce have witnessed the rise of Shopify over the last handful of years. And [headless] feels like this dynamic of graduating from Shopify to something bigger. It feels like it’s less of a case that Shopify has just improved it’s enterprise grade solution.
So the question is really for merchants going headless: is the value prop actually there, if you believe that Shopify is going to be at your end for awhile? What’s the right way to think about both being interested in headless and also committed to Shopify in the long-term? Are those two at odds?
Jordan Gal: I think that’s complicated. If it’s a yes or no question of, “Is headless synonymous with a bet against Shopify?” I would say it is, but I would also say it is a bet against the way Shopify currently exists. And the reason for that is I think what headless is – and I think what’s happening is a traditional case of unbundling. Shopify has a very wide horizontal platform that tries to satisfy everybody. And it is monolithic. It contains the front end, the checkout and the backend. And historically in technology, what happens there is the platform gets so big that it can’t satisfy everybody. And these individual verticals start to become a large enough opportunity for other startups to fill. I think that’s exactly what’s happening and it’s starting on the front end. And a lot of whether or not Shopify adjusts will dictate whether or not they participate in their own unbundling or fight against it, in which case I think it’s inevitable that Shopify will find itself in a position where it’s not going away anytime soon. It’s going to be extremely successful for a very long time, but it will start to have parts of its user base torn away. So it’s complicated because of what we don’t know. We don’t know Shopify’s plans, we don’t know their thinking, we don’t know their philosophy. It’s my opinion that if they try to prevent the unbundling, it’s not going to work for them. I don’t think it’s possible. It’s not how the internet works.
Mike Duboe: Yeah. It’s interesting.There’s a bit of a pendulum swing dynamic going on here. I think part of what Shopify has done is just made it dead easy to get a storefront up and running. And they’ve been highly focused on the emergent entrepreneurs that are kind of just getting started and in their own journey. Yet, some could argue that this proliferation of third-party apps has actually made it more complex for an unsophisticated merchant to navigate the benefit of having a true one-stop shop. Focusing on the ease of getting it up and running is a value prop that may be straight from Shopify. So where does headless play into this all? And is it almost antithetical to what I just said?
Steve Sewell: There’s definitely value in having an easy way. Like if you ask, “How do I just get started selling goods online?” It’s obvious: just make a Shopify store. And then of course, when you want to go deeper, you can start installing apps. Now, Shopify has sort of held this stance that they can do all the things well. So there’s definitely an advantage to just having everything all in one to get going. And there’s definitely an advantage of opening your platform to allow people to separate the front end – to separate the checkout and separate the big pieces – if there’s better options for them. And also just having one out of the box as well.
Jordan Gal: Well, you mentioned before about headless and people thinking of it right now, primarily, as speed performance. I don’t think that’s where it ends up. I think that’s step one. I think where it really ends up is about creative freedom. Right now it’s 2020, and yet online stores are still a direct analogy to offline stores. The storefront is the homepage, you have the category pages as the aisles, you literally have a shopping cart, and then you have a checkout line. That framework does not need to exist. You can do away with that completely. And you start to see the glimpses of it around social commerce, around people trying to take the transaction and put it all the way where the audience is – let’s say, the ability to buy directly on TikTok and so on.
We look at it as a hub and spoke approach. We think the storefront is your hub, but you can have an infinite number of spokes that allow for campaigns that are directly related to the channel that you’re going after. So you can have a TikTok funnel and you can have an Instagram funnel and you can actually have hundreds of different funnels based on hundreds of different campaigns on Instagram and so on. I think where headless ends up is in [the form of] more creative freedom for the brand, for developers, and for marketers, because you no longer have to live within that context of what is, right now, really just a visual representation of the database: here are the products, here are the categories, here’s the cart, here’s the checkout. That gets thrown out. And the reason that’s important is because that allows for a customer experience that matches your brand and what you want people to experience. And right now online, that’s the differentiator, right? How do you differentiate from someone who has 50 grand to invest in someone who has 50 million? Through the experience and its brand. And the headless front ends start to provide the type of freedom to differentiate.
Mike Duboe: Yeah, well said. One useful framing of this for our listeners – who have heard about the term and are maybe considering it but aren’t sure they’re at the right scale – is thinking about this: what if I’m an entrepreneur in e-commerce first learning about headless and I’m debating whether to go down this route. What are the considerations I should have? And what are the factors that would determine whether I should use a headless architecture or not? Another way of asking is, how do I know I’m ready?
Steve Sewell: I think there’s a couple of key indicators that can give you a good sense. One obvious one, to me, is if you’re at 10 million GMV or above, you should really be thinking about it, if you aren’t already. If you’re at a point where you’re actually making significant revenue and you’re on yesteryear’s technology, that’s probably almost definitely hurting your conversions because of the performance limitations of it. You should seriously be looking at going headless. Whether it’s a test or just a full conversion all at once, there are options there and we can talk about that. There are other considerations that make an ideal candidate, but that don’t make it the easiest to transition. If you already have developers on staff, this is something they should probably already be dabbling with. They should be looking at open source projects (Gatsby is a great one), connecting it to your Shopify or other backend and exploring a proof of concept of going headless. And looking at products like ours, Builder.
If you’re in the one to 10 million range, and maybe you don’t have developers on staff, it’s still something you should be taking very, very seriously. Whether you partner with an agency to do a lot of your build and optimization work, or you maybe have someone on retainer, it’s something you should really be considering. And if you’re at the state that you really have a good working channel – you know, you have people finding you, they’re purchasing, they like your brands, they’re retaining – you should really be considering going headless to look at if that can help improve your conversions, because it’s almost always worth the investment. If you’re a brand new entrepreneur, I would definitely say, just start with these sort of comforts of the existing technology. Don’t worry about going more in the areas of optimization yet. Worry about whether you have the right product and the right message. Do you resonate? Once you’ve got the channel working, start looking at your options of going headless and speeding up and improving that site experience.
Mike Duboe: I want to dig on that a little bit, because I think what you said is an important part of Builder’s thesis. But one interesting dynamic that I know we’ve observed in e-commerce is that merchants are able to get to pretty significant scale without having hired a big engineering department. Sometimes there are no engineers in-house. And we’re seeing brands doing tens of millions of revenue having maybe only a part-time engineer on staff. I think this is part of the thesis of Builder. We think that there’s engineering dependencies in places where there shouldn’t be. The speed of being able to iterate on one’s front end is one of the biggest determinants of conversion and thus revenue for a brand. To the point that you made around going to market via engineering versus marketing, what are the considerations, as you continually move up market, that Builder needs to think about?
Steve Sewell: When it comes to these enterprise e-commerce customers – which is where we started – they probably have this problem where marketing is dependent on engineers and engineers don’t want to deal with marketing. So it was just a horrible situation for both parties. And so they needed a tool like Builder to plug into their stack, where everything meets the engineering requirements. Everything’s blazing fast. Every future we add never has a performance cost. This is something that internally we call the conversion paradox: when you reach a certain scale and you start layering on tools and apps – an app for subscriptions, an app for reviews, an app for AB tests and personalization. What you don’t realize is all of these apps you’re adding to increase conversions are actually hurting your conversions, because they’re each slowing down your site one little bit at a time. In this case, that’s where we come in. We’re grounded in the new technology and in speed above anything else. And when we offer AB testing personalization, app integrations for subscriptions and reviews and other things, it’s all performance first. So it meets the engineering requirements, it’s native to their tech stack, and then suddenly, it enables the marketers to really go to town when creating, optimizing, and producing content and actually managing that storefront like they’ve always wanted to (and felt like they should), but the engineers and the technology had already always been a blocking factor. Then when you start going down, you start realizing that speed and the ability to move fast and optimize is not an enterprise-only problem. It’s a problem for everyone. And that’s why we’re really focusing on making this new technology accessible to everyone. With our Shopify app, you could plug in and actually start using it to speed up your existing Shopify store and do more with it. You could actually make it easier to take your existing content and bring it into a headless world and get that speed benefit without developers needing to be involved at all.
Mike Duboe: But what you’ve described as part of the irony of optimizing some of the other third-party AB testing is that you experiment to improve conversion, yet at the same time,having that installed on your site is actually a hindering speed. And so this is part of why I think it’s interesting to have both of you guys on Greymatter in pairs. Builder is more focused on front end stuff. And Jordan, I know you come at this from a different perspective. So maybe talk to us a little bit about some of the backend implications on going headless, particularly around the go to market, to marketing-versus-engineering.
Jordan Gal: Yeah. I had a lot of sympathy for Steve as he was describing all of that, because what you’re in the middle of – which is what we’ve been in the middle of for a long time – is you have to build for the future. Because right now there are early adopters – and the early adopters are the crazy early adopters who want to try the new thing – but it’s mostly people who are experiencing the pain right now. But in e-commerce in general, the organization is not engineering-driven, it’s marketing-driven. And so the way I always put it to my team is, “The tools that will win are the ones that make really complicated technology possible to people who don’t know technology.” It should make people who don’t know code be able to do amazing things on the internet in short, but also, let us get into the code if we want And right there, that gets really complex. So I sympathize with Steve on that.
What we did is something very similar, but we did it at the point of checkout. Speaking of the backend, I think this is where it starts to get complicated, because if you think about a scenario where – let’s just take a fictitious, $100 million dollar annual revenue brand on Shopify – and they are forward-thinking, and they need the performance, and they go headless, and they’re using Builder. And so the front end and the storefront is on Builder. And now the checkout goes through the Shopify checkout and then the backend they’re actually using NetSuite because they have sophisticated order management and they have multiple channels. Then they have a bunch of third-party apps in the Shopify ecosystem from Klaviyo to Privy to CartHook to whatever else in that scenario. What I think happens is that the backend becomes a commodity because the backend becomes irrelevant. It becomes invisible. It’s just an API that does things. And so it’s just a reliable commodity. And so in that world, what does Shopify do? Where is the actual reliance on the underlying platform from the brand? Their storefront is on Builder, all the orders would be managed by NetSuite, the third-party apps are doing all these micro necessities and services. And the only point of real dependence on Shopify is the checkout, because everything needs to go through the checkout, right? If you look at it in that way, it’s not surprising that our checkout product came to an early end. Because Shopify understands this dynamic, and their management team especially understands this dynamic. And so yes, headless separates the front end from the back end. But what is the backend, if it’s not just this reliable API? And in a world where if it gets commoditized, what that would tell me is there will be one winner, and that would be the most reliable API – Stripe, right? The one infrastructure that just does what it’s supposed to on a very reliable basis. And that’s it.
So I see what’s happening in headless, and I see front end solutions coming up, and I see back end, and I see Sale or Commerce.js and Swell.is and all these other apps, commerce tools and so on. But I don’t know what happens there when everything gets commoditized and becomes invisible. Is it specialization around subscriptions? I don’t know what happens there.
Mike Duboe: Yeah. It’s fascinating. And Jordan, you made a quick mention of the potential of platform risks that a lot of people building third party apps in this ecosystem think about often. What did you learn there? What advice might you offer for folks listening who maybe are a little bit concerned?
Jordan Gal: First, do not build a checkout product on Shopify. That’s pretty straightforward advice. It’s tricky these days because it is very, very highly competitive. What I think you need to do is really nail a painful use case, and then you need to establish yourself and then you need to make partnerships within the ecosystem, and then you need to grow. And then you basically can’t ever stop running because it’s so competitive.
One of the amazing things that Shopify did is they had this reliable API in the backend that allowed apps to build on top of it. And that is great for Shopify and great for the ecosystem overall. But when it comes to an individual company building on that platform, you need to just sprint the whole time, because the second you pop up as very successful, you have copycats, you have clones, and then you need to differentiate on things other than price, because that obviously leads so race to the bottom. It’s not easy these days in the e-commerce ecosystem. And what happens is people look at Klaviyo as the poster child – they did it. That’s the right plan: grow like crazy on Shopify and then expand to other platforms such that your revenue on Shopify makes up less than 50% of your overall company revenue. Then you can take a deep breath. That’s not easy to do these days. And so what happens is that companies pop up and they grow on Shopify, and then they try to expand outward to the other platforms, and the dynamic on those platforms is just not the same thing. The distribution channels are different, the app stores don’t look the same way. It’s a very different thing to attract customers on big commerce – it’s completely different than Magento, and a different planet on Salesforce and so on. So it’s difficult. The way I look at these things is do whatever you can to have a direct, measurable impact on revenue so that you can justify a higher price point, or you will be increasing the speed on your treadmill for the rest of your life.
Mike Duboe: Maybe the overly simplistic way of looking at it is that Shopify makes money predominantly as monetizing on merchant GMV. So, proving out that you drive merchant GMV without taking any of that off the platform – which in the case of CartHook, I know was a little bit tricky. One of the things you hit on with Klaviyo (just to bring up them for a second because they’re seen as the canonical example of how you actually gain adoption in this ecosystem), they seem to have managed the agency channel really well. What do you think the workflow looks like today (versus in the future) of brands working with agencies, and third party apps being in the mix?
Jordan Gal: I think both ourselves and Builder will inevitably work with agencies as a very important channel. In our previous life, with the CartHook checkout and upsell app that wasn’t allowed in the Shopify app store, we only looked at integration partners and agencies as our main channels because we didn’t have the app store. So we developed a playbook around how to be of service to an agency, how to make them look good and how to provide them with a tool that they were happy and proud to introduce to their merchants, to their clients. And then their revenue would go up and then the agency would do better. We basically formed an alliance between ourselves and the agencies. I don’t think that’s going away anytime soon. And if you are aimed at the higher end of the market, that’s where you want to be because those higher-end merchants don’t really look to the app store the same way that the long tail does. They look to trusted partners, specifically peers. That is by far the best channel – their peers telling them what they’re using and then their agencies and their tech partners and the apps that they’re already using and so on. So those existing relationships are the best possible channel to get your app in front of them.
Steve Sewell: I agree with that a hundred percent. When you look at the evolution, I think agencies today are doing a lot of build stuff and work where a lot of their value is an expertise. Where they can get higher margins and higher ROI across the board is their expert knowledge – their understanding of design and conversion optimization and everything across the spread here. Whereas today, a good chunk of that is just building things out. As you add more and better tools, they can navigate the landscape, they can recommend what’s right for you and set it up right for you. A tool like ours can make everyone a developer, but it doesn’t mean you’re an expert at how to optimize conversion . We give you all the tools to run your experiments, but you’re always going to benefit from someone who has already participated in the same type of experiments and had success with other merchants that are similar to yours. Agencies will always be an invaluable resource for being able to leverage that knowledge and give you the proper guidance.
Mike Duboe: Just to make that one a little bit more specific for the brand here, if you introduce Builder into that workflow, what does the agency-builder-brand workflow look like post adoption?
Steve Sewell: What it looks like today is that the agency is writing most of your storefront as code, like per Shopify and Shopify as the liquid code. This structure only gives the merchant so much ability to do much of any type of edits. When the agency chooses to use Builder instead, they can still create a great starting point, a great set of design system components that really are on-brand and spectacular user experience. But then as opposed to what you have today, the merchants can actually go in and start recombining those pieces in all new ways they never really thought possible and measure the conversions of every change that they do. And they can experiment with any type of AB testing. They want to try alternatives to anything they think would be a good idea. They can segment so they can show different content to people based on what’s in their cart, what they previously purchased, stuff like that.
It’s a huge amount of optimization you can do, and a huge amount of repurposing. And this is something in the technology world that we often call separating code and content. Your content shouldn’t be in your code and vice versa. So basically your developers can make the bare bones pieces that really quadruple, empowering your merchants to recombine them, to create all sorts of new things and optimize and all sorts of ways that were just not previously possible with that undertone of everything being blazing fast. So you’ll always get that significant win out of the box as well.
Mike Duboe: I want to move on to the topic of demystifying buzzwords going around in this world: progressive web apps. I think most people agree that commerce on mobile is moving more towards mobile web than to native apps. I think most folks would agree with that. Many brands are not building their own native apps these days. If you’re a transactional e-commerce site, it feels like
“progressive web apps” is a term that has become synonymous with a faster mobile web experience that feels like a native app, but it doesn’t require you to go and install a new app. That’s a lay man’s understanding. Could you make that more specific?
Steve Sewell: So the terms here are headless, Jamstack, and PWA, and I’ll break this down really briefly. So Jamstack is just the new technology that powers the building needed to make your site headless. So those can be somewhat used interchangeably. Sometimes you make a headless site and you’re making a Jamstack site. That’s the new structure we’re talking about on how to make a very fast-performing and more usable website in general. Now, to layer onto that is making it a progressive web app. That is like you said, taking the Jamstack technology and making it even more like a native app by adding the ability to download it to your home screen. So it’s living next to all the other native apps, adding the building to make it run offline, adding the building to send push notifications.
These are all new technologies that are available in this whole new Jamstack format and that if you bring them together, you can actually make a fast-loading mobile web experience that’s indistinguishable from a native app. You don’t have to download, you don’t have to deal with any of the roadblocks of the native app. You don’t have to worry about building a separate native app either. You can just have one experience that is blazing fast, both on that first load. So people just drop in and they’re shopping immediately, and navigating throughout is just as seamless as being on Instagram or any other native app you’re already using.
Mike Duboe: Right now, if you are starting a brand or you’re operating one at some scale already, it feels like it’s never been more competitive, and the barriers to entry are quite low. That’s kind of the point of a lot of the tech that we’re talking about. In the ad markets, going out and acquiring customers has never been more competitive than it is right now, and it’s also costly. And so it feels like executing really well across the stack and on the right concept is incredibly important. Are there any brands that you want to call out who you think are doing an exceptional job right now? What advice might you have for brands from the tech sidet?
Jordan Gal: Yeah. I think brands are very full of opportunity and very full of competition. That’s kind of their world right now. It’s a ton of opportunity and a ton of competition and it is now officially multidisciplinary. You can’t just be good at traffic. You also have to be good at retention. You also have to be good at branding. You also have to be good at partnerships. There are two brands that come to mind for me. Number one is Haus, the beverage company. They started off with a clever approach – their alcohol level is sufficiently low enough that they can mail it out. Just cracking that and seeing the possibility of direct-to-consumer sales with alcohol, that’s kind of a very smart breakthrough. It’s not surprising that they come from the liquor world and that they would have that insight. There’s something about Haus that as soon as you see it, you know it’s them. That’s almost like an Apple product, and that’s very hard to copy. There was an investment in art direction. That’s just one tiny piece of what they need to do. Then they need to convert properly, and then they need the fulfillment and the entire back end side of the business for shipping. So it’s not an easy category these days, but what you can do to give yourself an enormous advantage is standing out with your brand.
Another company I think of (and that’s one of our customers on CartHook) is Goli. They took a smart concept – apple cider vinegar, which is good for your health – and they put it into gummies that are delicious. And they work channels. It’s one of the most impressive things I’ve ever seen in e-commerce, how they handle each channel differently. And the celebrities and the influencers and the partnerships in each one is an amazing thing. So that’s their superpower. They have a great product, a good brand, and then they’re amazing at channels, so that’s what they lean into.
Mike Duboe: You raised two interesting points here, Jordan. You were making the argument that brand here is a great moat, and that actually mitigating a lot of the technical complexity and headaches that a brand would otherwise need to worry about and really just focus on building that brand is key to Haus’s success. And I agree with a lot of that.
The other piece is an interesting one on distribution and not working channel strategy. I think D2C in many ways is a misnomer in that all of these brands are starting digital, but then end up getting into wholesale and other channels faster. I’ve lived this world as being a scale spender on the usual suspect – digital marketing platforms and then you see the laws of gravity kick in at scale. So the need to diversify channels earlier in a company’s journey has never been greater. How should merchants be thinking about wholesale B2B in their overarching channel strategy here, especially as they’re going to market like a D2C brand?
Jordan Gal: The truth is, I don’t have a great degree of expertise on channel distribution and I would look to Web Smith and I would look to the Twitter mafia around D2C. That’s where I get that portion of knowledge for me. I look at the balance between AOV and LTV. It used to be that you could be good at one or the other, but now you have to be good at both. If I could give 30 seconds to plug our company, what we do is a little bit of both, but what we mostly do is improve AOV. And what that allows the merchant to do is improve their ROAS, which allows them to spend more money, which allows them to grow. And the way we do it is we allow for offers to be made in between the checkout page and the thank you page, so that’s a new canvas for merchants to work with. It works a lot better than pre-purchase upsells because it’s reusing the payment token. It makes it very easy to accept the offer. It’s just one click. The other part is that it allows the merchant to make a very relevant offer because it’s based on what the shopper’s buying in the checkout, so that can increase AOV. That allows the marketing team to just push harder. For every dollar they’re spending, their revenue goes up, their return on ad spend goes up and then they can start to diversify channels. They could take a channel that was not profitable and turn it profitable and so on. But what you hear a lot from people like Kristen LeFrance is just this harping on LTV and retention. In our companies, we see that in brands that are successful in generating revenue, but they’re still not doing well. It’s because they are looking for profit in the first purchase – in the first interaction of a customer. They are competing with more sophisticated, more well-funded merchants and brands that are looking at the LTV, and they’re looking at making a profit on the first year of business. They’re looking for that relationship with the shopper. If you are competing with a brand that’s looking at LTV and you’re only looking at AOV for that initial purchase, you are going to be in trouble, because nothing’s going to make sense to you. You’re going to look at the bidding on Facebook and say, “Why is everyone bidding this up if there isn’t enough margin?” It’s because they’re looking at it longer term. So that’s kind of where we play.
Mike Duboe: We had to build a lot of sophistication around this back at Stitch Fix, partially because it wasn’t that straightforward to understand downstream client value because there was such a lag time between when someone signed up and when we started to get some data after, for example, subsequent Fixes on them. But I couldn’t agree more on the importance of optimizing for downstream value versus upfront cost. It’s two sides of the ROAS equation, but we would always see more sustainable growth efforts from focusing on improving client value and improving our ability to go and attract customers that ended up being higher value. Predicting upfront what that looked like was always more important than just trying to be shortsighted and driving down CAC. Unfortunately in the digital marketing world and performance marketing, too many people do focus on CAC. It’s just been kind of the only metric that matters, and that will catch up to you over time.
Steve, let’s shift this to you. You have exposure to a different set of brands that are doing interesting things across the commerce stack. From a brand standpoint overall – either from Builder customers or not – what are a couple of examples you might call out of a company doing an exceptional job at this stuff.
Steve Sewell: There are really two that come to mind for me. One that I think of instantly is Atoms. What they did really, really well is they adopted headless quickly and incrementally. So they spun up a minimal headless site in a very, very short amount of time by just focusing on a couple of pages. And they set up a very simple way to throw up a couple of headless pages powered by Builder on their new tech stack. If the product page wasn’t ready or the checkout wasn’t ready, it just redirected back to Shopify. So I didn’t have to make it this whole huge effort and they didn’t have to over-complicate it, and they could start testing it. As soon as they started seeing benefits, they eventually went to all-Builder and all headless, and they did an incredible job at that.
One of the risks everyone sees is that this is all or nothing, and it doesn’t have to be that way. We’ve used Atoms as an example to share with other customers about the right rollout strategy with us as a product, and as a way to be able to achieve their goals quickly and without any real risk in jumping ship.
Another one that I love and comes to mind is Everlane. When we first started there – they were one of our earliest customers – we saw, early on, a hunger to move fast. And I loved it because when you get to a certain scale, things can really slow down, but they [Everlane] really have this internal mentality to keep moving and keep nimble. Whether you’re a brand new entrepreneur and you just have to try and find ways to move fast with few resources, or you’re a large business in a powerful brand, and you still need to be able to operate fast within a large team and within a sophisticated technology stack.
Everlane has this extreme ability to find good solutions and to leverage them. Now, these days if you go to the Everlane site, you’re jumping between stuff that’s been in their tech stock for quite some time made by the engineers, and Builder content back and forth like crazy. And they’ve made this exceptional user experience. You know, it’s just like what Jordan was saying. When you’re looking at websites, a lot of them just reflect their internal data. You go to one collection page or another, and it’s just the same page layout with different pictures, different products on it. It’s not interesting. It’s not enjoyable to browse when you were just sitting on Instagram and scrolling through content and land on an e-commerce store. You’re not trying to look at grids necessarily when you go to Everlane. You go to their homepage, you’re seeing quite interesting and different content every time you visit it. When you click on denim, you don’t see a plain old grid of denim products. You see a very interesting page with all new content. Every collection – even every product page – can have completely different content on it that gives the user a very compelling journey. It communicates their brand and their message. And they’re able to do that by having this innate drive to be nimble, to move fast, to run experiments; to learn faster and outpace the competition. Using tools like Builder enables them to do that; to discover these opportunities, to try them out without this engineering overhead or anything else. And it’s been amazing what they’ve done and I admire their team and Atoms’ team tremendously for that.
Mike Duboe: Yeah, you’re hitting on a really interesting point here. We’ve been spending a lot of time talking about the technical implications of this stuff. There’s also an organizational implication to adopting tools like Builder. I think when we talk about speed, actually, internal dependencies are one of the biggest determinants of speed. For instance, spinning up e-commerce landing pages or making quick changes to those pages is going to stand in the way of speed more than almost anything else. And so I think this is a fascinating point on just seeing the ripple effects of how adopting these no-code tools can actually really streamline an org and the way that marketers and engineers interact. It’s a really important point for folks to internalize here.
It’s time to close here, guys. This has been a great discussion. I think it’s been quite tactical and valuable to folks both on the brand side, but also developers and technology partners within the Shopify ecosystem. And more broadly, for those who are just interested in headless conceptually. So, thank you for going so broad and so deep on this. For our listeners, where could they find you to connect or learn more?
Jordan Gal: For me, @jordanGal on Twitter. And if you want to check out the company. it’s CartHook.com, and now you can finally find us in the Shopify app store.
Steve Sewell: You can catch us a Builder.io, or just search “Builder” in the Shopify app store and we’re there. You can also catch me @Steve80708 on Twitter. Remember those numbers.
Mike Duboe: Thank you guys. This is great.
