George Jagodzinski (00:00):

Today's episode is part of a miniseries that we will be peppering in amongst our other interviews. For this series, we go inside the walls of Intevity and hear from experts who are doing the hard work to help our clients. We discuss the patterns and the pitfalls, and we glean some insight from their many years of experience. I love showcasing our team. They're solution-obsessed, and in my very biased opinion, I think they're some of the best out there.

(00:21):

Today, we explore the topic of headless commerce. What is it, why you would or would not leverage it, and we discuss common pitfalls in leveraging full-service commerce platforms versus headless. I'm joined by Jason Anthony, one of our senior engineers who's relentless in his pursuit of solutions and performance, as well as Eric Webster, AKA Web, our director of digital solutions. Let's hear from the team.

(00:55):

Welcome to Evolving Industry, a no-BS podcast about business leaders who are successfully weaving technology into their company's DNA to forge a better path forward. If you're looking to actually move the ball forward rather than spinning around in a tornado of buzzwords, you're in the right place. I'm your host, George Jagodzinski.

(01:23):

Gentlemen, Eric, Jason, thanks so much for being here.

Eric Webster (01:26):

Thanks for having us.

Jason Anthony (01:27):

Thanks for having us.

George Jagodzinski (01:27):

All right. I'm excited. This is the first of our series where we're kicking off internal discussions. I'm always happy to showcase what the team's been working on, the thinking of the team. This one, we're going to start with headless commerce versus other forms of commerce. What are they, why would you go one or the other, the pros and cons, and ins and outs — as Lebowski would say, "the what have yous."

(01:47):

Let's just first start with what the heck is headless commerce and how does it differ from other things?

Eric Webster (01:52):

Yeah. Headless commerce is usually where you bring your own platform, and you're connecting through services and APIs provided by some sort of platform as a service or software as a service. There's usually a ton of reasons why headless e-commerce is a good path to follow. Usually, it's surrounding around performance or customization.

Jason Anthony (02:11):

Yeah. Just to follow up on that, I'd say if you're looking to go headless e-commerce versus some kind of a full solution vendor that you're coming off of, that's the time when you start to analyze and decide whether or not it's time for you go to headless or not. Usually, the full-service solutions are a good fit for a while, especially for smaller organizations. As they start to grow and start to get a little bit big, they start looking at how they can now customize and do little things that the full service solution doesn't offer right out of the box. It's another good reason to look at that.

George Jagodzinski (02:46):

I always equate this stuff, you guys have the pattern recognition that you can kind of smell it when it's time to move from one thing to the other. What does it smell like when it starts to become time to move on? What are the things that actually start happening?

Eric Webster (02:59):

It's usually when your product team is asking you to do things, and you're just like, "Uh, the platform doesn't do that, or we can't customize the platform to do that." Or when you hit a button on an app, and it takes forever because you've pretty much outgrown the platform that you're on. Usually, performance is a good indicator or customizations.

George Jagodzinski (03:16):

What are some customization examples? Jason, I'm trying to sell a sneaker, and the product team's asking me something. What are the examples of the stuff that comes up?

Jason Anthony (03:25):

Yeah. A lot of times, one of the bigger ones is loyalty. There's about a million different ways that you can incorporate some kind of a loyalty feature within your product. A lot of the full e-commerce, full vendor solutions, they may have something but it's probably not going to be as customizable as your product team can come up with. They may come up with a points system versus a coupon system, or all kinds of days ways in which you can discount, or aggregate points, and things like that. Usually, you want to be very creative in those type of spaces right off the bat, just to differentiate yourself because the loyalty programs are a way of keeping retention for customers you already have. You really want to stand out in that field and be unique. A lot of times, what we see is people don't use the actual out-of-the-box solutions that come with these full commerce solutions just because it doesn't have quite as much customization as they'd like.

George Jagodzinski (04:18):

I see these two examples play out a few different ways. One is that you'll have an organization that they just made everything so darn complicated over the years. Maybe they've gone through a bunch of acquisitions, they've changed product direction a bunch of ways. It's almost like, "Man, if you can just simplify and do things the way that the platform does it, your business will be so much simpler." You think that you're complicated, but you don't need to be. In those situations, I've seen them implement a platform, and they remove so much complexity from it.

(04:50):

But then there's sometimes where you need to figure out what parts do I want to be different. What is the special sauce? Loyalty's a really great example because you can really stand out, and it speaks to your soul as an organization, versus just point and click, choose a recipe. What have you guys seen out in the trenches? How do you determine what should maybe be a little bit more complicated or the is the special sauce?

Eric Webster (05:13):

Well, I think we always go back down to, at the end of the day, it all really comes down to your conversion rate. When you run out of ways to be able to push your conversion rate higher, usually that's when you go back to the product teams and you're like, "Okay, great. What are some ideas that we can have here to make this solution better?" Then you're talking about those ideas, then you go back to the platform, and you're trying to figure it out, and you're not seeing the answers you need. Those are usually really strong indicators that you've outlived the usefulness of your platform.

Jason Anthony (05:43):

Yeah. Then some of the stuff, it seems easy on paper, or at least it's easy to conceptualize. Okay, we know that Amazon and Walmart, for example, have found that even the smallest delay can equate to real dollar and cents. You say 100 milliseconds could equal 1% loss. The larger your organization is, the more that money actually impacts your business. When you just say, "Okay, well, we just want faster speeds." Well, that's a very complicated question depending on how your system has been set up. You've been architecturing these limitations based on what your full e-commerce solution had, so you start building maybe some caching layers or all kinds of different things to try and circumvent certain API limits and things like that. Now you've overcomplicated it, and now you've just really grown the scope of what just buying a pair of sneakers, as you say, on a website or something, could be so much more simplified if you could remove all of those pieces and make the performance better. But that's easier said than done.

(06:46):

A lot of times, you have those extra layers for reasons and now, when you go to try to take those out, you also have to re-architecture all of your solutions that you had before.

George Jagodzinski (06:53):

Let's dive into the easier-said-than-done part that you just mentioned. What happens out there in reality? It's funny because sometimes this will even happen after you've cleaned things up. You've got it all clean, things are performing really, really well, and then what, someone comes by and they're like, "Hey, let's jam this extra thing into the platform." What are the real examples? What happens?

Eric Webster (07:15):

I don't know, I think I look to search. I feel like search is one of those things where it becomes a little bit of a crutch for bad user experience at times. Everybody starts jamming more fields into search, and your database starts to grow of what your product has from a knowledge standpoint, and before you know it, your search solution, it is not up to par with what you need, either through customizations or just speed in general. That becomes usually one of the first places that companies start looking for. It's like, “Okay, great. How do we take the platform for search? How do we get the data out of where it is into another platform, where search can happen, where it can be a little bit more performant?”

Jason Anthony (07:49):

Yeah. Just to piggyback off that is we see a lot of people that want to get personalization results, especially for product recommendations is a really big target area that a lot of people focus on. How do we get the right product to move that needle, get that sale? They want to be able to get the right product that they're offering right in front of those people, by reading whatever information that they have right off the bat. As they start to add additional fields, as Web was saying, once you start adding different data points that you want to be able to track and then analyze so that you can then get the right product, those are going to add additional overhead, and that can reduce your performance.

(08:25):

All of the gains that you've just had by working on performance may be negated by a different team, in some cases, or a different solution, different features. All of these things work in tandem, especially when you're looking at e-commerce solutions. You don't really have a whole lot of points where ... At least that's the goal, is you try to reduce as many touchpoints because the customer buying that product when they see it and when they buy it. The more things that you add in between that step, the less chance you have of a conversion. Once you remove all of those steps out of the way, now any little thing that you add to that could increase the performance or decrease the performance, depending on what you're architecting. Really, your whole system starts to become more of a cohesive unit, and you have to be way more cognizant of the different things that can affect the needle one way or the other.

(09:14):

You may have goodwill intentions to say, "Yeah, we're going to track this thing so we get this right product for this customer," but now it takes an extra two seconds in order for that product to display, and that's not good. You really have to make that balancing act and figure out what works for you.

George Jagodzinski (09:28):

Yeah. Then that magnifies itself across the organization. The more complicated that gets, the more complicated the merchandising team's experience is, the more complicated the service and support teams and sales, and every single one of them, it just gets that much more complicated — really taking a scalpel to what it is you truly need to represent this product.

(09:49):

I'd be curious. I want to go back to the loyalty example because one pattern I've seen is, "All right, loyalty, we want to build it ourselves. It's going to be our special sauce." But then, that turns into, "We're going to build the whole platform ourselves." Is that the right path to go down? What have you guys seen in that type of scenario?

Eric Webster (10:13):

The weird thing about the world that we live in now, there's a bunch of silos. There's the best platform out there that does loyalty. There's a lot of micro-specification that happens, and there's a good reason for it. When you focus on just one service, one product, you end up doing it really good. The likelihood that there's one platform that does everything the best is very low.

(10:32):

It's one of those things whereas I like to think of us as mixologists, a little bit. We know a lot of the platforms and tools that are out there. When we're looking at a specific requirement we have for, say, loyalty, you're like, "Okay, great. What is the best loyalty platform out there?" But then you can also say, "What is the best loyalty platform? Which one aligns to our needs the best?" This way, you get the exact solution you need, not the solution that's just most convenient.

Jason Anthony (10:57):

I think what I've seen in the past is a lot of people will reach out to a third party vendor for their loyalty services. It takes a lot of the ownership off of having to build the entire thing from scratch. But it does have to be integratable. Your loyalty program has to basically directly inject into your basket or cart, entire stack. Whenever someone's buying something with your loyalty or adding discounts and all these different things, there's so much integration that has to happen with that inside of the existing platform right now. You really have to take a look at the exact e-commerce solution that you have currently and see if it even allows that type of customization for you to build something yourself.

(11:41):

But a lot of times, even when you're buying a vendor, you're still building yourself because you have to integrate that thing. Almost in all cases, are you finding a way that, if you're going to have some kind of a customized solution for that, you're going to have to figure out a way to make it work with what you have now. That's just part of the dance of trying to figure out what you can use from the full-service solution and then what you can customize. You always have to figure out what layer, what level of customization can we actually integrate with.

Eric Webster (12:14):

Yeah. I think one of the big challenges that everybody discounts is everybody thinks about integrations and connecting tubes and wires. The biggest integration is really the data. Getting the two data systems to align, where do you have parity, where are you using the same terminology. One place's revenue is different than another place's revenue. Trying to figure out what are the actual equations that you're using to generate some of these things and just making sure that we're all talking the same, that's one of the biggest things that I think a lot of people struggle with when doing really complex integrations.

George Jagodzinski (12:43):

Evolving Industry is brought to you by Intevity. We bring order to chaos wherever people, process, and technology converge. Our culture drives our solutions, and we are solution-obsessed. We see every challenge as an opportunity, every partner as a collaborator, and every project as a chance to share our values and commitment to excellence. Give us a shout. We'd love to hear your challenges and turn them into opportunity. Find out more at intevity.com. Now, back to the show.

(13:14):

Yeah, it's so important to figure that out prior to making selections. How is the data going to fit together? Not all the way down to a detail, but a good enough level. What's the experience look like? I find that so many people, they look to a platform as the easy button, and then maybe they get frustrated with it. That's when you see a really solid platform, maybe just get relegated to just part of business because buy the easy button. Then they see they don't have it, and they're like, "Oh, well, that's insert platform name's fault." But the reality was that if you really look at it as what are we trying to do as a business, what is our experience that we're trying to do, how do you figure out what's the platform best at, where we should us it? Where can it integrate, and then what do we bolt onto that?

(13:59):

Because what I find is when you just spread the peanut butter too thin, that's when no one's winning in that scenario. But if you can put the right pegs in the right holes, then it works great for you. I'd love to hear from stories from you guys on that.

Eric Webster (14:14):

Oh, man. It's really hard finding the right platforms to integrate with. There's so many different data points that you could use, and every platform's going to tell you that they're the best at everything. It's really hard to see through that.

(14:25):

I think you get a lot of experience working with a tool the first time you integrate with it. I think one of the things that we index probably more heavily than a lot of the information that just might be out there is really talking to business partners and other companies and doing a lot of research around… I wouldn't call it user reviews, but basically trusted people in the industry saying, "Hey, who does this the best?" Talk to them and truly try to figure out what was their process. What parts of that did they struggle with? Would they do it the same way they've done it before, or would they do it differently? When trying to figure out which platform you want to integrate with, I think those are really, really solid steps to make sure you're doing it the right way.

Jason Anthony (15:09):

Yeah. It's really objective, what is "the best." I think, a lot of cases, what you really need to do is you need to make a checklist of absolute must-haves. This product has to be able to do these things. Then on the other side of that, you also need to figure out what kind of cost and budget that you're looking at. You may have the best platform on one hand, but it's just out of your price range. You're going to have to make some compromises along the way. Especially if you have financial, fiduciary people that you have to respond to and present this solution to, you're probably looking at two to three, maybe even four different solutions that all have different pros and cons to each.

(15:47):

It's never really a real template that says, "All right, here's how we go about finding the right solution." In fact, we really just need to talk to our stakeholders and say, "Okay, what features do you absolutely have to have, you cannot live within?" Then, "What is our budget?" When you go down that road, then you make a clear picture of what it is that you're looking for. Down the road, often times we've found that some people actually make the wrong choices. They grabbed whatever fit in their budget. It may not have checked all the boxes, but we figure, "We'll build something now, and later on, we can always fix it later." If you're moving fast and breaking stuff, sometimes that just happens. You'll find you can actually run out of runway with those potential solutions as well.

(16:28):

Really, I've found, too, that people who are working with these full-service solutions, sometimes they're not even utilizing them the way that they should be utilized. They're not utilizing them how they were designed. They didn't quite follow some of the recommendations that the platform was provided to them. Maybe they inherited it from another third party that came in and just set it up for them and just gave them the keys, and they didn't quite know exactly how to use it. That happens often, too. Sometimes you go reaching for a tool when you already had the right tool right there in the box.

(16:59):

That's one of the things that we do when we go in, is look and we say, "Okay, what are the limitations that you're hitting? Let's take a look at the program and see if that's something that it already can do and we're just not utilizing properly." Especially with performance, usually, there's a lot of ways that people are abusing a system and not really understanding that they may already have data at certain levels that they could have just reached into and grabbed, as opposed to go fetching another full copy of the data. A lot of different things like that. Performance especially, we see that a lot. I don't think there's really a good one template that says, "This is how you select a good vendor for whatever it is that you want." You got to really assess what it is that you want from that product, and then, obviously, your budget is going to play a big factor into that.

George Jagodzinski (17:40):

Yeah. Then beyond check boxes, I've always been a big fan of the, "Let's see what this looks like. Let's do an actual — what's the actual use case look like when we actually go through here?” The big guys have every check box pretty much checked, as you can imagine. Just actually seeing what it looks like, and then ideally talking to someone who's actually used that out in the field.

(18:01):

Where I see people fall down is you buy the platform, you buy the starter consulting services from the platform or from a partner. That gets you set up for one division of your business, or one product line, or whatever it might be. Then you think that, on your own, you're going to be able to figure out how do we scale this across the organization, and then it gets messy there, for some reason. Why does it get so messy at that point?

Eric Webster (18:26):

Oh, man, I think it gets messy because a lot of people have different thoughts on what a thing is. Once you start to actually put your hands on it, then you really start to understand what its power is. I go back to the thing you just said, too. You got to talk to people who have used the tool before because you'll see around those corners a bit faster.

(18:48):

Things can get complex really quick. Everything's great and it sounds simple when you get going, but as soon as you start getting under the hood, sometimes things get really complex. It's just the way things are. There's no silver bullet for figuring it out faster. I think putting hands on it, as you said, is probably one of the best things that you could do to really understand it. Avoid getting locked into something before you have experience with it, too. Maybe that first contract's a little bit shorter than the others, and you give it a go. Or if there's a way to try before you buy, run a prototype or something like that. I think usually you can gain a lot of understanding very quickly by just putting hands on it.

Jason Anthony (19:26):

Yeah, absolutely. If there's always an option to try before you buy, you definitely want to try. Don't usually sign a long-term contract without ever having used the product before. Always look for that short-term in the beginning, and then you can always with the option of continuing the engagement later. It's very difficult upfront if you get locked into something that you don't really like.

(19:48):

I've actually worked for a company before where we were locked into a content management system that they were really ... The sales guys, hats off to them, they were amazing. They promised the world. This thing was going to do everything. The people, the stakeholders, they signed on. They said, "Yeah, I love it. Let's do it." Then we started playing with it, and working with it, and come to find out, it really didn't really deliver on any of the things that we originally intended to purchase it for. We were locked into a two-year contract with that, and basically, we never did anything with it. We just had to pay them, and it was a nightmare.

Eric Webster (20:21):

Yeah, sunk-cost.

Jason Anthony (20:22):

Always, always, always do that.

George Jagodzinski (20:24):

Yeah.

Eric Webster (20:24):

Sunk-cost is real.

George Jagodzinski (20:26):

Yeah, sunk-cost is real. Also, being trapped is real, too.

Eric Webster (20:29):

For sure.

George Jagodzinski (20:30):

That's why it's so important to have, no matter what strategy you're going down, having a proper data tier that gives you the flexibility, combined with really understanding what you want your experience flows to be because if you have your data tier and your experience flows nailed down, then you can swap stuff in and out. Contracts aside, you can have some flexibility that's in there.

(20:50):

I know one of my favorite stories also is, I don't know if we've talked about this, but there's always this promise that you're going to shut down all these legacy systems when you move forward with a big platform or a new strategy. Have you guys ever been somewhere where they've truly shut down all the legacy systems?

Eric Webster (21:07):

Well, yes and no. I think you're bringing up a very good point. A lot of data's only good in context. When you move on from a platform and that data is trapped in an old platform, and you don't have access to it, that's a ball and chain that you carry around for a very long time. I think there are ways, and I think you're pointing at, is to always make sure that you're taking the data from your partners, you're translating it into whatever your data model organization is, and you're storing it. That just makes it easier that, when you need to walk away from that other third party, that you can do so with knowledge that you're not going to lose access to information that you might need later.

(21:46):

If you're always trying to do stuff after the fact, it's always much harder than trying to do that alignment upfront. We talked a little bit about that, about making sure that your two data models align. I think that's a critical path that a lot of people just don't think about, that their data is just spread out to 10 different places.

Jason Anthony (22:02):

Yeah, I've worked at an organization where the hope was we were going to remove all of these legacy platforms. Luckily up front, the CTO at the time made sure that the new solution was going to be able ... He had to build all these data connectors himself and figure out the equations and stuff to be able to make sure we can say, "Okay, worst case scenario, can I still get into the old databases of the other system and be able to reference that data?" Because what happened was, after the migration, once we moved everything over, there was still some legacy information. It was just in a completely different schema that the new platform would not easily integrate. There was no easy way to migrate this data over because of the context of that particular platform. Having built a custom solution to be able to reach that data on command, whenever you need it, to go back to it.

(22:48):

Essentially, that system was never, ever shut off completely. We did stop paying for it because we didn't have to renew licenses, or any other things like that. But somewhere, on a virtual machine, in a network stack somewhere in that organization, is still running that specific piece of software, so they can always go back to find that, at least until retention runs up, maybe five, 10 years, or whatever.

George Jagodzinski (23:10):

I love those stories. We've been inside some of the top organizations in the world, and there's always one or two cockroach systems. I don't say that negatively because they were usually pretty solid when they were built, but they just survive. They survive for decades, and there's always a small team, or sometimes it's even just one person ... I say this to give solace to people who are listening because you might be frustrated with it, and I think it's just a law of nature that this happens everywhere. There's one person who's been there 20 years, they're maybe threatening to quit every year, and they're the only person that can understand what the heck is going on with that system. If you unplug it, all hell breaks loose.

Eric Webster (23:46):

Yeah.

George Jagodzinski (23:47):

Oh, I love those stories. What do you guys think about along those lines? There's never truly a one-platform-to-rule-them-all within an organization, right? I tend to lean towards let's minimize, let's have them all play-friendly. The example I always use for this is a large enterprise organization, they've grown through acquisition, they might have some product lines which are really small and simple, which just makes sense to leave on a simple e-commerce platform. If you try to put them on a big, complicated one, it would just make your lives miserable. It's okay for that to exist, along with the big investment that we made in the large platform.

(24:27):

I'm curious, what strategies have you guys seen that work with allowing these different-paced, layered systems to live at the same time?

Eric Webster (24:37):

I think I'd go back to the same thing that we said earlier, which is really just making sure that the platform or tool works for whatever its intent is. I've got this small product line that sits over the side of the business, and what have you. Its conversion rate is good. The customers seem to enjoy it. At some sort of point, consolidation, for consolidation's sake, is not always the right way. You got to move with intent. Why are we putting these things together? What is the value that we're going to get from doing that?

(25:10):

Simplicity doesn't always mean one platform. I think sometimes, we all feel it, too. "I've got this over here, I've got that over here, so many different things that I got to focus on." Sometimes, simplicity feels like just one thing, but one really big, complex thing doesn't always mean it's better than four really small, simple things. I think that's sometimes lost on businesses because we always talk about that unified brand experience or that unified customer experience, which of course, you want to have. You don't want your customers to ever be confused. But there's many different ways to solve that problem, which isn't just make it big, and complex, and slow.

Jason Anthony (25:51):

Yeah, I've worked for organizations where it was a huge driver to remove the silos, they say. "We want our people to be able to go into one program and only one program, and that's it." That dream is a very big dream. At the end of the day, though, a lot of the times, that one program that you go into happens to be comprised of smaller programs that all just use a solidary UI. You may think that you're solving the issue of the one platform to rule them all, but really all you're doing is just consolidating the view or the presentation layer. Everything else below it can just live in how it works. A lot of times, you really want to focus on presentation of all of these different systems, as opposed to trying to consolidate the systems themselves, which may not even be possible, just depending on how the data is structured at the end of the day.

George Jagodzinski (26:41):

I'd like to focus a little bit on performance, which we talked about earlier. Most importantly, the vigilance that's needed. Jason, I've heard you talk about some stories out in the field, as far as how vigilant you need to be. The picture I have in my mind is it's almost like that very loud personal trainer, that is walking around the office, and he hears someone crunching some chips in a cubicle. He just pops his head in there and he's like, "Hey, what are you eating over there?" I feel like that's how you are when it comes to inserting new tagging frameworks or whatever it might be. I'm curious, your philosophy on how do you remain vigilant and just real in the trenches, how you're getting people to stick to that? Or how do you clean up the messes?

Jason Anthony (27:23):

Yeah. I think a lot of it is being exactly like you say, vigilant. You really have to be cognizant of these things at a full scope, zoom-out level, where you're looking at every piece of connectivity between where the presentation layer is all the way down to the database.

(27:43):

What you got to do is you really have to look at where can you improve performance, and in some cases, you really can't. What you really have to analyze is — is it worth going down this rabbit hole of this particular spot here to reduce performance, or should we look somewhere else? When you're building things, or other teams are building things, and you just really have to keep your eye out and notice, looking over people's shoulders a little bit. Because a lot of times, some teams, especially like when you're working with teams that have front end versus backend, a lot of times the backend engineers, they may not even realize that they're doing things that are less performant or the front end engineers may also not realize that they're doing things as well.

(28:24):

Where we can see this a lot of times especially, is if you're using an API layer that uses GraphQL. It is an amazing tool. It lets people who don't have a whole lot of query language experience be able to fetch data, but they have absolutely completely disconnected the performance out of that. You can fetch whatever you want, no matter how bad it is. Then it's a challenge for the backend engineers to try and build something that allows that data but also doesn't allow what we call the clients to abuse the backend of the services. That's a big area of opportunity that we see. Whenever we see GraphQL, we go, "Okay, let's take a look at the different pieces of this GraphQL resolvers, and the queries, and the mutations, and all these things, and see where there may be some round-robin looping where they'll just go and fetch more data," because depending on how you write your schema, that system is going to fulfill that request, regardless of how bad it is.

(29:17):

A lot of tools that you really want to use are some application performance monitoring tools. And then, just go back and take a look and see what your users are actually, what the latency is. It's good, sometimes, we have just once a week, we'll just go into our application monitoring tools. There may not be anything on fire. There may not be anybody raising any alarms. Well, we'll just go in there and just take a look, and just see how the system is running, see if there's some areas of improvement that we can find, see some URL paths that, "Hey, these are taking a little bit too long. We really should be benchmarking these things."

(29:51):

An arbitrary question as well is, “Well, what's too long? How long does it take?” Well, in the interest of speed, you always want to get faster. You really don't have a baseline bottom that you need to hit for, but you do need to look at your trends over time, and then you can see if it's getting slower or faster, and you hope you're going in the right direction. That's where you can always just insert yourself, and just look and see how you can fix that.

George Jagodzinski (30:13):

Nice. Web, how have you seen keeping performance up?

Eric Webster (30:17):

I think Jason nailed it on the head. You draw a line, you say, "This is the bar for performance," and use a tool like an APM that just watches it. Then, when you hit that bar, you revisit.

George Jagodzinski (30:26):

Yeah. I liked the "if it's not on fire, still look at it" because every millisecond is real revenue. Just how fast can get it? Even if you draw the bar, it's like can we raise that bar? Can we raise it a little bit more? Can we raise it a little bit more? And really being vigilant with that, love that.

(30:43):

I have one more question for you guys. Before we get to that, is there anything that we're missing? Any last things that we want to make sure that we're talking about?

Eric Webster (30:52):

It would be important for us to talk about the cons, too. Managing headless e-commerce systems isn't always easy. It's not for everybody. I think it's really important for you to know the journey that you're going on. You're going to need a solid team of engineers that are helping support that process. There are ways that you can put it on rails and make it go smoothly. But it's not for the faint of heart. If you're looking for something that's hands-off, that basically is on autopilot, yeah, there's definitely point solutions that are probably better for that. But if you're really looking for that customized solution that you can really drive performance and results out of, there's where you look at a headless system. But you do need to know that you do have a team of engineers that are making sure that that stuff is performing good, and that as issues pop up because everything changes in the world, and you have to stay on top of it. There are definitely a lot of things that you might want to consider when thinking about going headless.

Jason Anthony (31:47):

Yeah, I totally agree with that. There's a lot of factors that are involved when you decide to make that decision to go headless. There are a lot of things that your full solution does for you that now you have to manage. Things like deployments, scaling, security oftentimes. Even liability in some cases, now may shift to your platform that you may not have realized. There's a lot of things that you really have to decide if it makes sense for you to own those things and if you're going to be able to build a team that's going to be able to support those for the future. It's one thing to go ahead and say, "Okay, we're just going to offload this portion of this system here, and we're going to hire a third-party contractor to build it for us." But then, you also have somebody have to stay on to manage that thing and understand how it can change over time.

(32:33):

There's a lot of different things that you need to make sure you're, as an organization, you're mature enough to be able to make that step and that investment. Oftentimes, you're always increasing costs. Very little are you going to decrease your costs, especially as George said, is you think that you're going to sell the business, we're going to be able to close these different types of systems off and no longer pay these bills. Instead, what we find is you're going to just pay additional bills for at least an interim time until you can fully migrate off of those solutions, and in some cases, never at all. You just really got to put those pieces in the back of your mind that, if you're going down this road, make sure that your pros outweigh your cons in that regard, that, hopefully, you can make enough sales to overtake whatever the cons may be.

George Jagodzinski (33:16):

Yeah. It's an unfortunate reality in anything that we do. Even I think about doing projects around my house, you're always going to underestimate how much work it's going to take. You head to the hardware store about five times more times than you thought that you'd have to. And it's going to cost you more down the road when you have someone come in and fix it. That's not to say doom and gloom. It's just to say, what you're looking at, you need to make sure that the ROI, or the flexibility, or the nimbleness, or the resilience, whatever you're trying to get at the end of the day, that it's truly worth it. And just taking a hard, cold look, and having a third party, selfish plug for ourselves, having a third party take a look at you and say, "Does this make sense for you? Are you painting yourself in a corner? Are you fooling yourself?"

Eric Webster (33:57):

The results are there, though. 100%, the results are there. You can drive a headless e-commerce system better than you can drive another platform because you own it. You get to go where you need to go versus, where's the roadmap for this service going? Are they even focused on businesses like me? Or are they focused on other business segments? The performance of the platform is there, but you have to have the backbone to get through it.

George Jagodzinski (34:22):

Yeah, completely agree. All right, thanks, guys. Last question. We'll start with Web. I always like to hear what's the best advice you've ever received?

Eric Webster (34:30):

Oh my God, the best advice I've ever received? Listen more than you talk.

Jason Anthony (34:36):

I second that, absolutely. You really got to listen a lot more than you talk, in most cases, just to understand the other party. Absolutely.

George Jagodzinski (34:47):

Well, I love it. Just aligned with that, as I learn a lot from you guys, not just here but every single day, working together. I appreciate it, guys.

Eric Webster (34:54):

No, absolutely. Thank you.

Jason Anthony (34:56):

Thank you.

George Jagodzinski (34:57):

Thanks for listening to Evolving Industry. For more, subscribe and follow us on your favorite podcast platform, and pretty please, drop us a review. We'd really appreciate it. If you're watching or listening on YouTube, hit that subscribe button and smash the bell button for notifications. If you know someone who's pushing the limits to evolve their business, reach out to the show at evolvingindustry@intevity.com. Or reach out to me, George Jagodzinski, on LinkedIn. I love speaking with people getting the hard work done. The business environment's always changing, and you're either keeping up or going extinct. We'll catch you next time, and until then, keep evolving.