What is Headless Commerce and Static Site Generation? Interview with Nacelle CEO Brian Anderson
What is Headless Commerce and Static Site Generation? Interview with Nacelle CEO Brian Anderson
Darius 0:02 Welcome to the retail tech podcast where we speak with leaders and entrepreneurs involved in all aspects of retail and commerce. I'm very specifically the host and producer. This interview is being recorded on clubhouse and will be published on retail tech podcast calm. After the first set of questions, we'll be answering audience questions. So please stay on and raise your hand to come up on the stage in a few minutes. Today, I'm speaking with Brian Anderson, a CEO of a company called nwsl. They work in the space ecommerce and headless commerce. And they work with brands and other retailers in this really interesting new leading format of creating websites and delivering them. How are you today, Brian?
Brian 0:56 I'm doing well. How are you?
Darius 0:57 Fantastic. Thank you for joining me. So let's start by maybe a background on yourself and how you came up with the cell. And then we'll talk about what the cell does.
Brian 1:14 I actually ran an e commerce agency prior to signing myself. And I came across the problem in a way that I think is not unique to other folks in the agency business. There was a big gap in the infrastructure that we needed to execute head was built properly. And although we were doing good work, and really helping our clients move forward with their headless builds, unfortunately, we weren't making too much money on our head was built because of some infrastructure issues that we could talk about. And so, you know, what we realized is okay, well, we can go out and build this infrastructure. But if we're having this problem, we're quite confident other merchants and other agencies will have this problem as well. And, you know, what, what if the agency business model is actually the wrong business model? What if what we should be doing is building, you know, a system that other agencies and developers can build on top of, and then providing that system as sort of more of a SaaS business model as opposed to a business model? We're billing for the hours.
Darius 2:22 Okay, that's very interesting. The so let's talk some about the concept of headless commerce, which also, I believe, is directly related to the static site generation or not, maybe you can educate me on that.
Brian 2:41 Yeah, I think this idea of static site generation is really a reimagine ation of how the web works. For a long time, the paradigm has been one where, you know, a client meeting your desktop computer or your phone, sends a request to a server, the server, does some calculations, probably queries, the database, pulls in some API data, packages, all that up into HTML, and sends it back onto your computer. So this is the request response cycle. That has been the paradigm for decades. Section ratio is this idea that instead of having that process happen 100,000 times, you know, within a minute, when there's a lot of traffic going to your site. It's this idea that, hey, what if we only did that process once, we only asked for the server for the information once, and we pre generated all that HTML, that you know, as a result, that way, you know, you don't have to hit the server. Every time a request comes in, you can sort of pre generate with the whole website looks like and then distribute, you know, those pre generated pieces across the world and something called a CDN. And it's really a revolution in the way that the web works. And it's really fueling, not only headless, but also trends that you'll hear of like jam stack, you know, mostly powered by nella phi and Purcell that offers hosting to static generation.
Darius 4:08 So is is headless type of static site generation or the other way around.
Brian 4:18 So the relationship between hovers and static generations is interesting, in order to execute static generation, you, you can't really be working within a proprietary finding purpose. In fact, I would probably make the argument that it's very hard to do static information without separating the front end and the back end, meaning to power static generation. It's such a different process than the way traditional data systems work. And so you know, if you look at some of the popular monolithic systems out there, like Ruby on Rails, and it's something people have heard of, you know Django for Python, these frameworks were built in a way that's conducive to static generation. And so what you really need is a technology that treats the backend differently from the front end so that you're free to bring in a process like stack generation, or do its thing, if you will.
Darius 5:18 Okay. Yeah, that was, that was also sort of my understanding. So it's good to hear, I wasn't totally off, because I think, you know, unless you don't have that separation between the front and back end. It's really, you know, I don't know how you could actually do like, static generation. So one of the questions that I've always had about static generation is the type of the website, right the interface. So I, I thought that it's a lot better suited for content related where this content is not dynamically generated based on like personalization. But it seems like there is a solution for the other way, too, which is really like ecommerce. So I'd like to learn how do you do like personalization? And really, you know, displaying the right products to the, to the to the user every time they load the page with us? You know?
Brian 6:21 Yeah, I think you can, there's a couple of approaches to personalization. And I think you've recognized something that's really important. There was a bit of a movement of headless in the content management side before in commerce. And what's interesting to notice is something you pointed out with a blogger or otherwise static website, should be in theory, or conducive to static generation where you know, things like prices doesn't change. Things like personalization, and recommendations aren't, you know, it's not quite as dynamic in the world of, say, a blog or a website. Without e commerce functionality. What happens when you get into e commerce? First of all, why would you even want tag generation? I think is a really good question. And, you know, if you if you start to take a look at his cell, in the case studies that we have available on our website, we talked a lot about how static generation improves page load speed, and is built for mobile, which means that conversion rate and average order values are increasing. Subsequently, versions can grow faster, the revenue increases. But how do you manage things like personalization, and that's really, part of the problem that we're filtering to solve is this idea of actually being able to statically generate multiple different pieces of the website at once and doing it at such a large scale, that you could actually statically generate many different variations. Without without worrying too much trouble. And I think that's that's part of the questions that we talk about here at Ansel relates to well, if you remove the bottlenecks from stack generation, what are the actual possibilities? So I agree with your assumption here, it is harder to do things like e commerce because of the dynamic nature of it. And really, that's very much why why we exist. In fact, if this were easy to do, it's unlikely the cell would exist, or have the traction that we've had today.
Darius 8:18 Okay, that that's, that makes sense. It almost reminds me of the performance issues that we are currently having with blockchain. And we know that we're going to solve them. And we need people, like, you know, who are you know, so many startups and people that are, you know, working on this to solve these problems. So it's good to see that the cell is actually attempting to, to fix this problem or come up with solutions for it.
Brian 8:48 Yet, again, to be fair, I think that blockchain issues is a slightly different engineering issue. But some some, you know, there are some themes that run through it that are interesting. This idea that there's a certain scale involved, is also interesting. I mean, from a startup point of view, the thing about the cell that's unique is, you know, we did sort of start, start a company where, you know, one user comes in or two users come in, and that kind of grows over time. You know, we have some really big merchants using our infrastructure. And so as soon as we launch a new merchant, we sort of take on or inherit their scale, if you will. So scalability and flexibility and performance have always been the three cornerstones of myself from day one. And, you know, really building out a product and engineering team that understands that is something that's that's really core to what we do here too, so.
Darius 9:41 Great. So now, let's talk a little bit about the concept of headless commerce. You know, we refer to it a bit, but you know, I like to see if we can get a more educated definition of it from you.
Brian 9:59 Yes, I think the overly simplistic definition of headless commerce is that it's a separation between the front end and the background. And that is definitely certainly the definition we've all accepted in the industry. But I think that definition unfortunately, doesn't really explain the value nor the history or, or the context of headless. So let's start there. Had this this term in engineering started in 1975, with the company, IBM. And what they were doing is shipping. I mean, they had a big server business, they would ship servers across the world. And they had sort of introduced a new type of server called a headless server. And unlike its other servers that it was shipping at the time, this particular server did not include a monitor or a keyboard or mouse. Okay, so as a console as a whole thing. But it was, it was the decision maker of the binary, the decision of the Bible, to actually choose what monitor and what keyboard they wanted to add to the to the terminal. Fast forward to today's world, we can see a bit of an analogy between what headless commerce stands for today. And what those servers were back in 1975. By separating the front end and the back end, you're able to build a custom storefront on the front end, that's using the technology that's best for the merchant, as opposed to using a technology that's very prescriptive or predefined for merchants. When we look at the popular and traditional ecommerce platforms that exist today. Many of them were built over a decade ago. And I think there's a couple of trends like explosion of mobile, and the overall demand for more architectural flexibility in the e commerce stack. These two trends have really fueled this idea that merchants need the ability to pick what's right for them, they need freedom of choice, they want to start to build things that are custom in areas where they can differentiate like the customer shopping experience. And so unfortunately, buying a system or fully commerce stack that is very prescriptive, and has everything built in for you. It's not really fulfilling the need of both mobile and the need for merchants to start to differentiate themselves amongst all the competition. And so coming back to this idea of you know, 1975, and the servers were shipped without the market without the keyboard. What if you could build your e commerce stack the same way? What if you could create infrastructure in the system that wasn't prescriptive, but it's that gave you the freedom of choice to choose the components and to build the customer shopping experience that's right for your brand. And that's really the true value of habitus.
Darius 12:51 Great, that's, that's a really interesting history. And I think it's a good analogy. So how does, let's talk about how the cell actually works, I took a look at the video that your engineer did. Very interesting. I'll add it to the, to the, to the show notes on the website when it's the interview was released. But let's walk through that process. And we're nwsl actually sits in the stack.
Brian 13:26 You know, a lot of the merchants that we work with today. And I think this is missed by the larger community outside of e commerce about almost every minute Congress created new standards, but ecommerce merchants already have infrastructure in place. So for example, we partner with Shopify, we adore Shopify here and sell. And merchants are on Shopify, and they already have all their product catalog information in Shopify, they have other customers in Shopify. Ideally, they're leveraging some of Shopify new technology like Shopify pay that creates this wonderful one click Checkout. And so I think a lot of headless solutions that are market, they try to be monolithic in nature. And that's not what we do. We have an ethos here in the cell where we preach, we want merchants to keep the text that they have if they want to keep it in the endorse it. And so instead of building out a content management system within the cell, and maybe a product information management system within the cell, and checkout, we said wait a minute. headless is about freedom of choice. Let's not be prescriptive, let's let the merchant choose what's best for them. And we will work on sort of the first specialty if you will, to sell is this idea of data ingestion. We spent a lot of our engineering resources not on building CMS nonbuilding. But instead laying the merchant type of CMS in the pivot that's right for them. And we do the hard work of buying into that those data sources and pulling data in, in what we call our data into
So what this means is you can actually go into our dashboard. And if you saw the video that Devin posted, you know, he talks about how you can click around, you know, make a couple clicks in our dashboard, and all of a sudden your data can flow from, for example, Shopify into the cell. I will also emphasize that you can do this if you don't have Shopify, if you're a custom, you know, the the other extreme end of this is is your fully custom stack, maybe your technology was built in house, and no one's heard or seen your system outside of your organization. You could simply use our data ingestion. Aprs to send data in will ingest that data. And we use eventual technology. So we call our whole system Event Stream. And sort of the next phase once that data is ingestion is adjusted is our API. And we offer a graph qL API that pairs together all through data sources, so all of your content or your product information, information about, you know your order history. And we offer it as a highly performant highly available API. We don't we don't normally publicly state this. But I'll say here, there are no rate limits on our API. And we have some pretty interesting stories. For example, last Black Friday, we actually had a merchant, that, for some reason, one of the developers there Thursday, before before Friday, had pushed a loop that was just pounding our API, again, hundreds of 1000s of requests going into Black Friday. And truthfully, no one, no one's actually noticed it, because it didn't affect performance in any way. The only reason why we noticed it is the Wednesday after we, we had noted that this merchant had something like you know, 223 times more API calls and everyone else during Black Friday. And so what this represents is our modern sort of very forward leaning and cutting edge architecture, our stack is radically different than most stacks out there. In fact, very rarely where we grab a traditional database to store data. You know, we don't think that that is performant. Enough for the modern world of progressive web app and static generation. It's our API is extremely performing. And, you know, the data ingestion engine does does the work of binding to the choices you make the vendors that you pick, pull that data in, and then we send it down through our API. But he has a special not only was it really built for static generation, first and headless first, but it's it's a graph qL and in federates, all your data into one. So it makes it very easy for developers to come in and grab popular frameworks like react and view and build a really performing commerce on top of it. Those are primary two things that the third aspect that we focus on is we are a managed infrastructure service. So while you might have to host your front end pw A's somewhere, you do not have to deal with DevOps, or hosting any of this back end technology, we take care of that for you, you simply send data into our API, when you pull data out of our API, don't have to worry about anything else. And when you find that merchants appreciate this, because they don't want to differentiate themselves by building out DevOps teams, they want to differentiate themselves by building out a customer shopping experience that really speaks to their bring into their customers. All upgrade definitely also seen sometimes merchants that aren't on, you know, a monolithic system, want to build out their own path and their own CMS, and that sometimes that's the thing in our world, because again, you know, if you would like to differentiate yourself in something like Price Books, or you know, something like a content management system, we really support that. And, you know, again, you can use our API's to kind of be the connective tissue to bind all your systems together. So you can see the the promise of headless, it goes beyond just the separation between the front and the back end. And it really starts to speak to operational excellence, you know, now your, your, your merchandising team can really pick the content management system that's right for them. You know, your fulfillment team can really pick the order management system that's right for that. They're, they're not bound and prescriptive technology. The fourth thing we work on, and I think this is where a lot of other folks in the space fall short. They, we have something called front end accelerators. So they're essentially open source projects that are Developer Relations, team managers. And a lot of you know, there's there's a lot of components built in both even react, you can pull these components down, you can actually push them right into production, if you'd like. But most of our versions will use them as sort of architecture diagrams or references. They'll build for these components. They'll alter them the way they need them for their brand. And it's interesting, some wonderful way to get up and running in this headless blog quickly. So really our four areas of core competency data ingestion, API, performance management, infrastructure and farming accelerators. In a nutshell, that's what we do here at MSL,
Darius 20:00 Well, that, that's going to keep you pretty busy. I think those are really interesting big problems that you're you're focusing on.
Brian 20:10 Yeah, we're having a ton of fun. Yeah.
Darius 20:13 So again, just to better understand like the the position of nwsl in the stack, would it be fair to categorize it as almost like a CDN.
Brian 20:28 So we don't get to senior, we provide data. If you think of saturation, there's really three ingredients that go into it. There's the code that's written that actually executes this function. There's this server that that code is hosted on to actually perform the execution of the saturation. And then there's the data that needs to flow in. We provide the third piece of the puzzle there, which is the data that's flowing in, we ensure there's no bottlenecks, you could pull in 1000s of objects within seconds with our API. But once the saturation execution is completed, there's now the static files to the server. And those static files get distributed to a CDN. So this is downstream, if you will, for loss, and often are merchants right now are choosing, you know, for cell and netlify as the CDN provider for the static files. Now, there's other CD ends is involved as well. For example, Shopify offers a CDN for all the private images that you upload. And a lot of our merchants are choosing to headless content management system, like a contentful, or a sandy prismic is another one. strappy is another very cool one. And usually those content management systems will offer an image CDN for the media that you upload into their system. So we're certainly not a CDN, but we do support, you know, operations that that send data to the CEO.
Darius 21:53 Okay, great. I'll ask a couple other questions. If anybody has would like to join, please yet raise your hand and I'll start to bring up some people. What do you think about the I'm sure you've heard about the Mach stack? Yeah. It's so this would you would this be considered a part of the Mach stack or, or typo?
Brian 22:18 I think it could be, I think, even this idea of composable progress that that that Gardner kind of touts, I think this fits squarely into it. In this in this idea of composable commerce, which in my opinion had was congressman composable. Carver's are sort of pointing the same and I'm sure someone from Gartner were here, and they would dispute that. But the idea that you can build your stack from the top down, and I do like this idea composable to kind of describe that this cell is the connective tissue that ensures that these disparate pieces that you're plugging in, don't get lost in the mix and ensure that data is flowing properly, from the back into the back end, but also from the back end to the front.
Darius 23:01 Okay, yeah, we actually do have one of our friends, Jeff, a previous Gartner analyst, but I think he's probably busy. And just listening in. So
Brian 23:12 to be clear, I think the work that Gartner is doing around the spaces is fun.
Darius 23:17 Yeah, yeah. I mean, that's really, really interesting, valuable work that being done. So going back to the video. And so let's go through like that type of an implementation a customer comes up, you know, they they decide to start using the cell, if you can walk me through the steps of what it takes to actually get set up.
Brian 23:47 Right. And so by a customer, a merchant is interested in exploring, what the seltos Yes, okay. We have to always differentiate that because customers in our world are our shoppers or that have already purchased merchandise. So the first thing that originally has to identify is, and this is an important question, but it is timeless, right? for them. This is something they want to explore. And I think the really easy way to solve that question is to ask yourself, if you are a part of a brand and an organization that use technology as a way to differentiate, and as a way as an investment, as opposed to a cost. If you view your technology stack as a cost center, and you want to keep costs as low as possible, potentially has isn't quite right for you. But if you view technology as a way to increase your growth, as a way to reach more customers, and as a way to improve the customer experience in a way that will overall increase your top line, then I think that list is worthy of exploring. So I used to say that there was a certain threshold for revenue but I just don't think that's true. I think this is the real litmus test to determine if this is right for you, you know, are you willing to invest in engineering in order to get a great return out of it? Or is your goal at your company right now, to live at the budget for engineering and use that budget for things like, you know, maybe maybe media buying, that's not to say that that headless media buying don't go here that they absolutely do when you get an increase in conversion rate, you know, helps things like, you know, your roles. However, if you are an organization that doesn't view technology as a way of winning, or differentiating, then I think headless is should be a little pause before you get into it.
Darius 25:41 So if I can, yeah, if I can actually dive into that's a very important point you brought up? How do you how do you know, when you talk to a merchant organization? That they are actually they really understand what you just mentioned about, like using technology as a competitive part of their business, not just cost? How do you determine that?
Brian 26:11 I think we asked them, you know, I think I think I think it's becomes immediately apparent I, we have a strong belief here in Excel, that you don't if Shopify is about arming the rebels, the cell is about marketing, the developers. And our tools are technical in nature. And it's a suite of tools that you use for engineers and developers to build and craft wonderful shopping experiences that are really pleasurable. You know, we have proven that this investment is does give a positive our line. But if merchants aren't comfortable with that, or if merchants aren't ready to invest in engineering, then it becomes immediately apparent that, you know, maybe headless isn't quite right for them. Yeah.
Darius 26:56 Okay, so. So, the reason I ask that is a lot of times like you ask people is your organization agile? And everybody says, of course, and then you dig in, and you find that they're really not that agile as they thought they were. So that's why I'm wondering if there are some like red flags that you, you detect yourself? Not even, you know, the customer actually asking? Like, the tool sets that they use the technologies that they use that really tell you, if the company is really like progressive.
Brian 27:32 I think a good question to ask early in the sales cycle is what's your spend on engineering? And if you could get his return on that spend, is is still interesting to you? Even if you would have to increase your your engineering budget.
Darius 27:47 Okay, okay, great. Okay, so now let's continue with the next step after the we've determined that headless is right for the merchant.
Brian 27:58 So I think there's a number of different what we call cloud had those cloud configurations. The very common one is that you're on a monolithic stack, as a merchant. And that can mean anything from Shopify, from Magento, to bigcommerce, but also all the way up to ATG or hybris. So it spans the ranges of SMB all the way up to enterprise. If you're on a monolithic stack, let's say shop five, you can go into the cell, and you could click around with the dashboard as your access token, let's just use the example of Shopify. So you would add your access token to an app that's created on your your Shopify store. And it's easy to do that in cells go in and start to ingest the data from your Shopify store to fill up its own indices. And then that data will be immediately populated and pushdown fapi. I want to start, that process doesn't take too long. But once that's done, you're able to make API calls. And at Ansel, again, we have a number of these starter kits that you can deploy, right to nullify or resell. And you can start to get a feel for what it's like to have a pw a front end. Now, these certificates will give you an idea of what it will be like but it won't necessarily be on brain. You can think of it as a theme or a starting point. Or, or an accelerator. And so what will happen is often, you know, merchants will kind of kick the tires, if you will play with the sandbox a little bit deploy one of these starter kits to see what it's like with their product data on a TWA. And, you know, from there, they'll make the assessment, okay, this is this is something we want to invest in. And so, you know, they'll they'll pull the project down into their own machines and start to write code that that customizes those starter kits to you know what they need to To be unbranded be a great shopping experience for their particular customer. That's the general form.
Darius 30:07 Okay, great. We have a question from David. So I will bring him up. Let's see how the Hello, hello. Hi, David.
Unknown Speaker 30:22 Hi, I had a quick question regarding that specific point you guys were talking about like, why would you go you were talking about Shopify for a backend and Mpw for a front end? Why would you go with Shopify, when you can just have your own data controlled using like stripe checkout system or something? Because if I'm gonna code something to begin with, like, like, let's just go with stripe for the back end, and it's free, so they're not having to charge you any overhead.
Brian 30:49 Right? Well, first of all, I mean, tribalism is totally free, they're taking a percentage of your checkout, just
Unknown Speaker 30:54 to be clear, but talking about the monthly charge, because stripe is embedded in Shopify payments as well.
Brian 31:02 Right? I think if you wanted to just use stripe directly, there are other things that e commerce you also have to consider. So a content management system, Product Information Management System, in order management system, these are all things you have to consider. Now, I have thought of the we're not prescriptive in terms of what the merchant wants to use. If you want to build out a custom stack, we endorse it. And I think that that's the wonderful thing. I would want to ensure that, you know, if you're if you're going to custom build, that you're aware of, you know, the requirements for that merchant, you know, hey, what happens with scale over time? How are these systems interconnected? I do think it's more than just a check out. But I do love this approach. And I we do endorse it here.
Unknown Speaker 31:53 We are. So when it comes to CMS is actually stripe did a great job recently, you can add your products, you can control customers, and you can control that, right from the stripe. back end, like again, you can have a look at it once you log into stripe, and you can do it manually. And obviously you can do it all with the API too. But yeah, that makes sense.
Brian 32:16 Yeah, so in our world, we consider the content management system to be different from the pin and different from the customer data source. So you know, often our merchants are using a system like contentful, to really manage not just their blog, but actually manage all the components on the page, they can drag and drop to move things around. It's a wonderful interface. Another another company we're really fond of in this space is Sandy. It is interesting to say what do you do with your stripe API and maybe send these API to build something custom? And that's very exciting, and certainly a world that we endorse here.
Darius 32:51 That's a very interesting question, David, thank you. So Does, does that actually give us any signals or indication where stripe is moving forward in their product? roadmap, like getting into almost like the commerce application size,
Brian 33:10 stripe for a long time has had things like checkout and subscriptions have been built and product built into their schema. We'll see what happens with stripe I think. Let's see how stripe and Shopify behave over the next two, three years. I do think it'll be interesting to watch.
Unknown Speaker 33:30 I think stripe is totally developer friendly. But when it comes to actual people look actual actual customers. It's totally not friendly at all. Like it's very hard for an average person that's not a coder or developer to actually go in and set up a checkout instead of a front end facing. It's it's incredibly hard.
Darius 33:53 Good point,
Brian 33:54 right. I agree with that. Yeah.
Darius 33:55 Yeah. So David, what what do you do i do you have an agency?
Unknown Speaker 34:01 I do not. So I started as a freelancer, I have a computer science degree. So I started as a freelancer in the content creation world. And I was mixing that with my ability of coding. So I can come up with sites while doing the marketing piece of it, manipulate API's, and play with all that fun stuff. And now I am working at a pharmaceutical company in Southern California, I'm doing digital marketing with them. And I build portals and I build things like that for them.
Darius 34:32 Okay, that's very interesting. So this, this probably would be an interesting, I guess, lead to talk maybe a little bit about the concept of low code or no code. And where all of this these tools are moving towards, so that you don't even need developers to set up a an e commerce site even to this level of complexity.
Brian 35:01 This is a really. So this will be the most contentious part of our conversation, guys. We are the opposite of no promo code, we take the extreme opposite view, we are actually here to argue and empower developers to build something special. The things that are low code are the things like data ingestion, when, you know, things like DevOps stuff that we want to extract, extract away technical complexities, like interoperability away from the developer, so that they're free to build something that differentiates their brand. And that's impactful. But in terms of low code, no code headless, in my opinion, hackers and low code, no code are like oil and water. They're totally different things.
Darius 35:42 Okay, I love hearing, you know, dif different views on on this. I mean, I mean, to be honest, no code and local doesn't actually make sense. Because there's code everywhere is just that is self service or not self service. But the so it's so is the argument, the thought that you cannot really build really, highly customized websites, at this point without the use of a, like a good developer that really can go in and, I guess, tweak things to that really granule level? Is that the argument or
Brian 36:22 that's that's my, that's my personal argument. I think. I don't know if that's an accepted view, but as a cell that we believe that we are here on the developer to make something that's special. And, you know, this is a pendulum that's been swinging, right? I think, now, five years ago, you know, sort of six years ago, Magento was so popular because it was open source, you can go in and change the code and customize it the way you want. And I think shop close does fantastic job of sort of liberating, you know, SMBs, and giving them the ability to actually scale your whole business without having to write code. The problem that we now find ourselves in is a lack of customization. And basically, these brands, it's like, they're sort of all buying the same software off the shelf. So and they're running the same playbook with buying media and buying ads. And so how do you differentiate yourself as a brand? And it's our strong opinion that, you know, giving developers API's and seeing what they can build with it is, is the way forward e commerce for the next generation of both b2c and b2b brands?
Darius 37:29 Okay, yeah, I mean, also, the other thing that I've seen is that, you know, there are a lot of like, no code or local applications, like the really cool ones, I mean, workflow, bubble. But what I'm hearing is, people like entrepreneurs are saying that I just, I just hired a bubble developer. So even those applications are not that simple. That person can just do the work. So I think the idea itself is more of a marketing thing.
Brian 38:00 Nice marketing. Yeah, trick, right. But by the way, I think works was a fantastic product. I think what plaid did, there was something really special. And I think his vision for what happens next is very intriguing. But I would sell when it comes to e commerce, we take the extreme opposite stance on this.
Darius 38:22 Yeah, yeah. I mean, I mean, the point I'm trying to make is that everything takes time and work to do. So. If you take the time away from maybe a developer, you're going to have your marketing person that now reads needs to really get re educated on using a tool again. So I agree it's, it's it's really a marketing, I guess, Cam format or strategy, but it is they're going in the right direction, because I really, like I think it's good to be able to lead marketers experiment as quickly as possible. So it's that, that speed of experimentation with as a business person is the key for me, regardless of I mean, of course, you have to have performance on the website and all of the other things. But so anyway, if you have time, there's one more question, Brian,
Brian 39:22 stories real quick to that point, I want to be clear, when you pair a content management system into your staff using yourself, you can the marketing team is free to build landing pages on the fly without a developer, they're free to sort of merchandise, their website the way they want it to drag and drop to move things around. But the key and the thing that that's very important, is that it's a headless CMS. And so I think the issue is a lot of these low code, no code solutions, like web flow, for example. It's a monolithic system, and it has to be because it has to control both the front end and the back end in order for its low code, no code solution to work. We do see a lot have sort of low code, no code solutions popping up in headless. And I really questioned that. Because I don't know how you can be headless and also tightly bound to your front and your back end together. So it's an interesting trend. And we'll see what happens with it. But I think merchants are very suspect of, of low code, no code and headlights. I don't think those two things go together.
Darius 40:20 Okay, interesting. We have another question from Joseph, which is a Shopify developer. I don't know if I've, I'm trying to bring him up on the on the stage, but it's not letting me so. Oh, okay. So let's see if this worked. Maybe we'll take one more question. Joseph, are you up?
Brian 40:39 Hello.
Darius 40:40 Hey,
Brian 40:41 hi, how's it going? Um, yeah. So I just wanted to add to that topic of low code, no code. And while I do agree that right now that that's not really like happening, the low code, no code, do you see, do you see a future where code becomes so accessible, or this low code, no code becomes so easy that everyone's a developer.
It is certainly my hope that
we become more literate as, as a society, in ideas of coding and engineering. I've always noticed, especially in the startup world, with developers tend to have a little bit of a chip on their shoulder, maybe like, oh, like, I'm an engineer, I'm a developer, and you're, you know, you're in XYZ department, but it's not like your product. So you know, we're somehow better or something like this. And I kind of roll my eyes at that. Because the truth is, I think, as a society as a whole, we've done and we can do better. I think we need to be more inclusive, overall, but but you can go, you know, sit yourself down in an afternoon and learn, say JavaScript, you can write some basic code. And you can start to get familiar with these concepts very quickly. So and I think things will get better over time. By the way, we're dropped JavaScript chops from the top down. So we wrote front end created JavaScript to write server code in Node. And we actually deploy our infrastructure as code using a system called Ruby with JavaScript. So we're JavaScript through and through. But, you know, there's things about JavaScript that I despise, like there's not really one canonical way of doing things. So I'm hopeful that maybe the next wave of frameworks and languages make it even easier for for folks to pick up engineering and programming. Yeah, but but I don't, I don't think this will ever be eliminated. If anything, the languages that easier and easier to interact with. And the skill becomes more about architecture, and mapping and planning and knowing how to manipulate data and how data flows. I think those are still the big problems, even if you know how to write some code. Or even if the code could magically write itself thing a decade, you still need the architecture mind in order to understand how to build systems. I think that
Unknown Speaker 43:05 takes you back to the first point, Brian, about how it's not going to be as customizable. Because it's gonna
Brian 43:24 Yeah, but I feel like theoretically, you get to a limit where it's like, it's so accessible with all these libraries that anyone can almost do anything. And then I agree to your point that architecture is kind of the next wave of where the expertise comes in. Yeah, we'll see what happens. I'm intrigued by it. And I hope that we have more developers in our world, writing more code, because that's the world that we are built for. And that's the world that we will endorse. And it just these trends are encouraging to me. But low code, no code, that doesn't make sense to me quite yet. Or maybe it's just the way it's branded. Right? Maybe what we're really trying to say is pages and come into the result dashboard and click a couple of things. And all sudden your data is flowing is that no code needed. But I think what we're really doing is empowering developers to use our tools once that data is ingested to build something really special and unique on top of, and to do that, not only is it the idea of actually cutting the code, but it's also the idea of architecting the system and how the shopping experience will be.
Darius 44:29 Great. Yeah, that's a great point. I personally liked the the phrase self serve better than no code. But, you know, again, it's, it's, I think, probably the functionality is the same as to what they're trying to achieve. So well, Brian, thank you so much. I guess too close. Are there any interesting news we should know about what's going on what we look for, from the cell in the cell in The rest of this year? And are you looking for anything hiring people? any announcements you'd like to make?
Brian 45:09 Yes. So we are, we are hiring quite a bit. Our team has grown rapidly over the last two, three quarters here since our series a financing. So we are looking for great developers, because this code doesn't write itself yet. We're also looking for great architecture clients. Outside of that, we're hiring.
Darius 45:33 Think we lost your
Brian 45:35 success developer relations? We do. We are actively hiring for sales roles and marketing roles as well. So we have a careers page on the website. And I encourage you to go check it out. And also, I think the one topic that I'd like to leave everyone thinking about right now, in today's world is really very much consent management. And it's not something we do in our business. It's nothing that I'm involved with. But the majority of websites and web stores really that that are selling online that I see they are blatantly egregiously ignoring consent management rules that I think it's a sleeper trend that not enough folks talk about. And I think it's something that can be really disastrous for a lot of brands that are growing fast right now. And so I do hope as a community, we start to have more proactive conversations around consent management and tracking and how this looks going forward. This is beyond with third party pixel, this is a conversation around, okay, my data is flowing back to something on the server and I don't know where that's going. And it's certainly beyond third party tracking, although that's one piece of the puzzle. So, consent management, if you're not familiar with it, like give it a look and read about it for 1015 minutes this afternoon. I think it's something that everyone on this channel should be aware of.
Darius 46:58 Thank you. That's, that's very interesting. This sounds like we need to set up another interview with you. These just going to that. Be happy to garden. Awesome. Well, thank you so much, Brian and David and Joseph for asking questions. This interview will be published on retail tech podcast.com in a few days and all the best to Brian and in the cell team really impressed with what you guys are doing.
Brian 47:29 Thank you so much for having me. Durness. Cheers.
Darius 47:31 Have a good day.
Unknown Speaker 47:32 Bye bye. Thank you for having us.
Darius 47:34 Bye Bye, guys. I'm closing the room. Bye bye.