Selling a Better T-shirt on Headless Architecture With Apparel Brand Kotn

Find out how apparel brand Kotn used Shopify's Storefront API to power their headless build.

Ask Benjamin Sehl, self-professed hacker and co-founder of ethical apparel company Kotn, if you should go headless and he’ll flat out tell you no. “Then, if they're really insistent, I ask you to tell me why, because most of the time there’s a little bit of a misunderstanding about what it means."

"There are people who think it’s about a speed boost or it’s going to improve conversion rates. I think there are a lot of myths you have to dispel first. For Kotn, it really came down to the boundaries of what was possible.”

Sweat the small stuff 

Kotn’s ecommerce site didn’t start as a headless build. Its initial online store was created in response to a big idea that Ben had back in 2014. It was a particularly hot New York summer, and he found himself transitioning outfits from cheap white t-shirts during the day to considerably more expensive white t-shirts for nights out. The difference between shirts was obvious: cheap shirts were lower quality and expensive ones were higher quality. So Benjamin started wondering what it would take to make a better, high-quality t-shirt for a fair price. 

He shared his musings with his girlfriend at the time, now wife, Mackenzie Yeates, who had a background in fashion direction, and his friend, now business partner, Rami Helali, whose grandfather lived in a community where Egyptian cotton was farmed. To solve the problem of making a better shirt, all three decided to go to the source. They flew to Egypt and spent time on farms and in factories, working with people throughout the supply chain. It became evident that the lack of transparency and traceability in this chain was creating a dichotomy of cheap and expensive shirts.

This discovery cemented a cornerstone of Kotn’s philosophy: to set the standard for conscious creation and consumption. 

House of cards

Back in Canada, with 500 t-shirts in inventory and a passion for well-made products, Kotn launched its Liquid-powered Shopify store with a custom theme Ben hacked together. A self-taught developer, his eye for design led him to learn CSS and HTML in the early 2000s so he could make his MySpace page look cool. By the time Kotn launched its first product page, he knew enough jQuery to be dangerous, had built several WordPress sites, and wanted to build from scratch. 

“When we started on Shopify,” Ben says, “one thing that was really exciting to me was Liquid—just not having to do wp-config files, all these crazy PHP hooks, and all this extra stuff like with WordPress—it was like a breath of fresh air.”  

He appreciated the cleanliness of the templating language and the ability to ship without breaking anything, because Shopify CLI displayed errors before Ben would push out changes.

As Kotn’s product offerings and customer needs grew, Ben learned and hacked along the way: one custom piece that used alt tags on images to match the color picker stacked upon another custom piece, stacked upon another. It was becoming cumbersome for ecommerce merchandisers to manage the content, and new engineers were hired to run day-to-day operations. There were two different Shopify stores that supported multiple currencies, but only one content site that was built on Jekyll and used Forestry CMS. After a few small code refactors, plenty of piled-up tech debt, and an urge to build custom interactions unique to their customers, it was time to think differently about building for the next five or 10 years.  

Evolving Kotn’s tech stack  

Ben hired Rares Crisan as Director of Engineering to start from scratch. With a desire for total control of the site’s design, a need for a familiar dev environment, and interest in server control, Ben and Rares began envisioning a build that would also allow the shopping experience to match customers’ mental models. They decided to build their custom storefront using the Storefront API. It was a lot—and it didn’t all happen at once. 

First, they used the Storefront API to replace the product page and resolve the hack that used alt tags to match image colors with the color picker UI. The theme and Forestry content site remained untouched. Next, the Forestry site was replaced with a CMS called Sanity to power the content, while the theme and two storefronts stayed the same. Then, the collection pages were replaced before the final phase of merging the two multi-currency stores into one, rewriting the product page and building the cart and checkout all at once. 

“Then we were on a sort of fully headless build, doing it in a way where we could be loosely coupled enough to have some freedom as we went, but not too deep in any one area,” Ben says. “It was incremental. I think it actually de-risked a lot and allowed us to ship faster, get to insights faster.”

With more control at their fingertips, the focus from app management and creating work-arounds from old hacks shifted to building in house and relying on API feeds. Before going headless, little customizations that would really enhance the site’s user experience would require installing multiple custom apps to facilitate all the different use cases. But as a headless build, they could customize and control even the smallest aspect of the site experience. For example, including a module for product reviews that matched the look and feel of the page while still performing became as straightforward as connecting with APIs and controlling it. 

Empowered community, powerful tools

Another important aspect of Kotn’s decision to go headless was the opportunity to use React. Now in-house developers could build reusable components that weren’t only consumer facing but could extend throughout the rest of the internal application. The strong developer community that uses and supports React played a role in the decision to adopt the technology, according to Rares.

“When you’re picking a technology and have a small team that needs to move very nimbly, you want to look at the number of people who are working on projects using that particular piece of technology,” Rares says. “That community helps you accelerate your solutions, because there are lots of sample applications. There are people who have already built something you’re trying to build, in a way that maybe isn’t right for you, but you can look at the code and extend it to work for you. That was how we thought about choosing React. And we extend that thinking to all other types of technologies we’re looking to use.”

Rares led the team to add tools to their tech stack that were already championed by the developer community. They chose Redis, a well-understood tool that works with key value stores, for caching. They looked at Docker to create and deploy immutable images and at Kubernetes to support their potential need for multiple sites if site traffic is too high. Rares believes well-established communities are integral to great tools, and additionally, great builds. 

“These tools are all really well established with really broad areas where you can talk to developers, find existing things, and build on top of them,” he says.

And you have that reliability—and community and reliability go a long way in building scalable, consistent, and reliable applications.” 

The community surrounding Shopify’s Storefront API and robust documentation for it were central to Rares’ decision to use it for Kotn’s headless build. Another tool in the tech stack, working with the Storefront API helped speed up development considerably, thanks to the strong documentation Rares and his engineers could leverage, like code samples and examples for writing an actual endpoint. The community forum of fellow developers and Shopify engineers made it easy to ask questions, get help, and find solutions to challenges rather than having to search online or check Stack Overflow.  

I’ve worked with lots of APIs from lots of different types of vendors or third-party applications, and Shopify’s is probably by far one of the best APIs I’ve worked with,” Rares says.

“The biggest challenge with working with APIs is finding the information you need when you’re stuck. Sometimes documentation only takes you three-quarters of the way, and then you’re stuck at that last quarter. You’re trying to find some forum or some obscure article where someone’s written about it. That’s not a thing you have to do when you’re working with the Shopify API because of how well written and how well documented it is.”

For Ben, the power of the Storefront API came not just from the community supporting it, but from its ability to boost internal operations. “We’ve used the Shopify API to do things like business intelligence as well as build internal tools,” he says. “It’s an interesting example of the types of experiences you can create for a customer using the Storefront API, but there are a lot of things you can do that serve the other personas who interact with your web interface, who might not be your end consumers but can still give a lot of productivity boosts to things internally. Internal tools are a particular passion of mine.” 

The good, the hard, and the challenging 

As with all journeys, changing course takes guts. Deciding to build a headless architecture for Kotn sped up the team’s ability to ship. It allowed Ben and Rares to create the ideal environment in which their engineers would thrive. Developers could code in a medium they were used to writing in, using familiar tooling and patterns. But it wasn’t without its challenges. Adopting a headless framework meant losing some of the built-in benefits of Shopify’s platform. 

“Some things you don’t have to think about when you’re on Shopify is how fast you’re loading products, how your pagination works, how your collections are organized,” Rares says.

There’s a really important speed element to loading things and presenting them to your user. And when you’re on Shopify, you’re not thinking about that because that’s being handled for you. When you go headless, you forget that is what’s happening.”

Engineering a solution for load time was an immediate challenge the team addressed, because the site performance was starting to negatively impact the user experience. Customers will bounce when product pages don’t load quickly enough. The team built a caching architecture so they could load products upfront faster without needing to aggressively ping the Storefront API for products every single time a user navigated to them. Another part of the solution was building a centralized store that users loaded products from, which was the store that interfaced with Shopify to keep performance up. Rares strategically focused the team on solving performance and scaling issues that ensured customers could access the products they wanted, that were actually available in inventory, in a meaningful way—trusting that the infrastructure Kotn was sitting on was going to handle the rest. 

Ben’s feelings about making the move to headless echo Rares’ realizations about redoing the basics in order to make sure the foundation was solid. “One thing I wish I knew before making the switch was how much upfront work was going to have to happen, especially all the things around querying,” Ben says. “One thing that originally got me so excited about Liquid, which I don’t know if I fully appreciated it back then, was having all of that query data available like the object in Liquid. So you could say ‘product.title’ and see your title and some of the filters thereafter. Laying all that infrastructure for all of our queries was a lot of redoing the basics. There were probably 500 hours or so spent just laying the queries and patterns before we were really able to be productive and accelerate.” 

What’s on the horizon  

With the infrastructure built, the team is now fully focused on making a unique, differentiable ecommerce experience that helps people find what they’re looking for and discover new things. They’re not trying to reinvent the web, change the way people use servers, or write new ways to code sites. And the new innovations to adopt, whether it’s a new framework, language, or way of hosting an application, mean one less problem for Rares to think about. 

“You can spend all day trying to solve every single problem, because there’s no shortage,” says Rares. “There’s always a little thing here or there. But you really only want to write code for the problems you want to solve. You don’t want to write code for everything, otherwise you’re doing too much. But we want to be a company that’s focused on great online experiences. We want to just focus on that problem. Hence, the less code you write for the other problems, the more effective you are at the code you are writing for the problem you do want to solve.” 

Ben agrees: "Shopify covers 80% of our needs, and I think that’s common across all merchants. It’s that next 20% where headless comes in and where we really spend our time. What we’re trying to do is let Shopify handle the stuff they do so well, and we can focus on what makes us unique. That’s where we’ve really gone with our thinking around being headless.” 

If focus is everything and time is limited, both Ben and Rares have a strong sense of what’s next for Kotn. Their headless architecture has allowed them to think big, secure in a solid infrastructure they can build upon. Ben says he’s excited for the future of ecommerce: “There are a lot of exciting things on the horizon in the next five years—mobile apps, voice, AR, VR—and I want to be ready so we can really take advantage.”

Whatever the future holds, Kotn will be better positioned than ever before. Its new architecture and fresh mindset can handle anything. “The world, and especially the developer community now, is just so broad and so large that it used to be really important to move fast and break things and to get out ahead,” Rares says.

“But now I think it’s more important to be thoughtful, to think about why you’re building the things you’re building and who you’re building them for, to make sure you lay the right foundation. That way, you can keep serving that audience at a regular, reliable pace.”