Builder.io, Unbundled

As Techcrunch put it, "Any e-commerce business has to constantly change its digital storefront to ensure accurate inventory is represented. But to launch a new product or test a homepage placement often requires the need to tap busy developers for guidance, slowing down the process."

Builder.io enables its customers to create the ecommerce experiences in a drag-and-drop system, that they connect to their tech stack without developer support.

Builder has raised close to $20 million over two rounds of funding from Greylock Partners, Imaginary Ventures, Good Friends and Firebolt Ventures.

We had the pleasure to interview Builder's CEO/Co-Founder, Steve Sewell for this piece. We’re excited for Steve to give us an insight into working with various brands on a very large opportunity for the ecommerce world. 

1. Can you tell us a bit more about Builder.io and its mission?

It's actually pretty simple. The large mission is to democratize coding. With Builder.io, anybody, whether you're an engineer or not, has first-class access to high quality coding tools. We make real code visual and accessible and make it possible for anybody to do wildly amazing things without having to learn anything.

The product is easy to figure out as you go, all the features are drag and drop intuitive. Where we really had the strongest wedge right now is with e-commerce. E-commerce brands have many use cases, they’re constantly creating new promotions, testing new landing pages, and trying new personalization campaigns across their site to drive more conversions. Our product’s integration with their stock, their catalog and powerful sort of conversion tracking and optimization tools really, really hits home with people today.

‍

2. We've discussed it together before, but how do you see your category evolve? You’ve hinted that you are creating a new category with Builder.io.   

We don't fully fit into an existing category really well. I think that products that offer visual building will evolve pretty significantly. I do think this specific idea of visual coding, making hard coding tasks accessible will be its own category.  And in e-commerce, we are already seeing it start to transform how people manage their storefronts. We have people using builder.io to optimize their Shopify storefront. They migrate to a headless storefront and all the builder content still works the same workflows and everything is optimized for headless. I think we'll continue to expand ultimately past e-commerce and ultimately across all sorts of players.

3. When does switching to Builder make sense for brands to consider? 

I would say if you're just starting out and you have no sales, you could probably use what Shopify has out of the box. When you get to the point you've got a growing brand that is acquiring customers, then you can start to optimize it, which means that you’ll be running experiments and making them more personalized for customers - that’s when Builder.io comes in handy. 

If you're finding that you're having to reach out to developers, for what feels like non-complex tasks like updating simple content on the homepage, running a simple AB test, or making editorialized versions of your product pages, that's when you should really say, ey, builder can automate a lot of this work. Builder saves the developers for more interesting work and more high value work. Builder helps unblock your marketers and merchandisers to really move and learn faster.

‍

4. Generally, how do brands evaluate a potential commerce tech solution like yours? 

They’ll usually weigh it against a couple of things. One is internal resources, so they’ll ask themselves “What does it cost for our agency partner or internal developers to be making these constant modifications to our website, to be creating landing pages and campaigns? Will it cost more/less than Builder?” Builder is usually a massive cost savings for all of our customers compared to using agency/developer time. The second is performance and flexibility. 

They’ll ask themselves “So does Builder perform well? Does it integrate with my other systems? Does it work with a variety of tech stacks? If we change infrastructure, can Builder adapt with us?” The answer is yes. Usually, Builder is evaluated against a big mix of tools, but usually the mix has holes that we plug so often we're used alongside anything else that you might want. 

‍

5. How do you think critically about building integrations with the largest ecommerce platforms like Shopify, WooCommerce, Magento, and Headless? 

We want to provide good integration, so we can't necessarily spend our resources integrating with everyone and everything. We do very much think that our strongest product market fit is a more up market, e-commerce brand or merchant. So for us, that's usually a brand doing $20M GMV and above. On the Shopify side, we focus on Shopify plus,  that's why we don't focus heavily on WooCommerce. We do prefer a more modern tech stack. So we love headless and we love when you're using Shopify plus and headless. Magento can be great as well. It's a little bit fragmented, right but it is great and something we also support.

‍

6. What are the top three key integrations that make Builder work so well? 

First: Brands love our Shopify integration. And, customers love that you can connect custom catalogs as well. Everlane has a completely custom platform, and they’re a great customer of ours.  Second: Our front end integrations like front end of Shopify or front-end of react. Brands love our react integration on how you can use it with wild flexibility and really great performance.

And so that's a big key one for us.  Third: our CMS integrations. Brands may use something like Contentful but they might use something in-house, and Builder’s ability to pull data from other CMS systems is really powerful and really loved by our customers.

‍

7. What advice would you give to commerce technology founders who are building business models like yours? 

Be customer obsessed.  The number one mistake I see founders make is because they make assumptions. They put their head down for 12 months and they come out and release something to the world and realize it was a miss. The really successful ones I've seen work closely with merchants. They find merchants who have a problem that they believe they can solve and they build the solution with the merchant, constantly involved. The merchants are always testing the beta versions, giving feedback, sharing, what's working, what's not working, and what features and capabilities they need. That makes the biggest difference. 

The key is to be honed in on a good problem. Find potential customers who are willing to try a rough beta because the problem is so strong, work closely with those merchants and then start expanding from there. I think that's sort of the key to building a product that people truly need. 

And the other huge thing is - customers will always tell you they want lots of stuff, but it's only when you actually put it in their hands and see if they either use it or don't that you really know if you're solving a problem the right way. If you get the feedback that demonstrates that the need is there, you can lead to product market fit, which is critical.

Once you have product market fit, you certainly need a growth model, some way of acquiring customers in a consistent, repeatable way. That can be a tricky thing as well, and requires a lot of trial and error and exploration and learning what others in the industry do and trying out different paths until you find one that really works for you, that you can repeat and amplify and make efficient.

‍

8. Without giving too much away, what tips would you give b2b founders during their sales process? 

My best advice, especially if you're a technical founder, is to try and blur the line between product and service. I got some of the first customers at builder by finding out what the technical needs of the brands were, and then I built for that. I told my first customers - If you were to pay a team of engineers to build this, it would cost you an enormous amount of money, so pay me $99 a month to build everything that you need instead. That's hard for people to say, no to. 

And this process supports the prior point, make sure you're building what people need, because you're essentially working directly with them building out almost exactly what they need.

So our first customer, I was building a whole lot of stuff for them, which made the product better, which was great and charging very little. For the next large customer, It was similar, but there were  little less services with a higher price for the SaaS and then was able to do that multiple times kind of shifting that needle incrementally until now.