How Agencies Use Headless Tech to Solve Technical Challenges and Win New Projects

Headless website architecture may seem like all the rage, but how does it apply to real-world technical challenges?

In this panel discussion, you’ll learn more about the ways our Agency Partners and their developers are solving difficult technical problems with headless solutions.

Check out the video below to find out when headless makes sense to unlock new potential for your projects, when to rely on classic WordPress, and how to get your development team on board when adopting new tech.

Speakers: 

• Rami Perry, Senior Partner Account Manager at WP Engine 
• David DiCamillo, Chief Technology Officer at Code & Theory
• Adam Davey, Director of Technology at CandySpace
• Dennis Ngin, VP, Digital Experience at Wpromote 
• Scott Jones, Founder and CEO at Illustrate Digital

Transcript: 

RAMI: Hello, everyone and thank you for joining us for this DE{CODE} panel. I’m excited to be joined by leaders, some of our top strategic agencies, to dig into the role that headless WordPress plays for their team and their clients. We’ll start off first with some introductions so you can get to know our panelists and then we’ll dive right in for the chance to learn more about how headless can help you win more. Dave, would you like to start us off with an introduction?

DAVE DICAMILLO: Sure thing. Hello, everyone. I’m Dave DiCamillo. I am the CTO of Code and Theory. We are a digital-first creative agency. Over the years, we cut and made our name doing publishing platforms, so very content focused.

And our first experience, probably, doing headless, was probably back in about 2017-2018. Our current site is headless and we’re doing a lot of work today with a lot of clients. And it’s the predominant architecture we’re driving towards. But good to be here and look forward to the discussion.

RAMI: Hey, Scott. You want to introduce yourself to everyone? Hey sure thing Hello, everyone. I’m Scott Jones. I am the CEO and founder of Illustrate Digital. We specialize, primarily, in the WordPress platform, and have a real strong focus on creating frustration-free and engaging user experiences across everything we do.

SCOTT JONES: We’re still quite new to the headless game. We’ve been carrying out research and development for 12 months or more, built our own framework for headless WordPress and yeah, we’re still in the early days of that. Excited to keep talking about it.

RAMI: Thanks so much, Scott. Adam, do you want to jump right in?

ADAM DAVEY: Yep, great. My name is Adam. I’m Adam Davey from Candyspace. I’m the director of technology there. We are a London-based digital agency focused on designing, building, and optimizing digital products.

Yeah, we started our headless journey a couple of years ago now and I’m constantly having conversations with clients about headless. I’m right in the middle of a headless build right now. So it’s an exciting journey and I’m looking forward to talking today about it.

RAMI: All right, Dennis, you want to wrap us up with intros?

DENNIS: Hi, everyone. My name is Dennis. I am the vice president of Digital Experience for Wpromote. We’re a performance marketing agency, driving growth for our challenger brands. My team started down the path of headless in 2019. They’ve been doing it ever since. We actually adopted the WP Engine Atlas product last year, and successfully launched a headless site within two months. So I’m super excited by sharing our story.

RAMI: Thank you all for joining us. So we’re here with an audience that’s going to have probably a fairly varied background and experience with headless, some folks that are just starting on the journey, some that have been journeymen in regards to headless.

So what I would love to hear a little bit more about is when, in each of your either professional career, or at your agency, was it like, OK, it’s time, this is either the opportunity or it’s the inflection point where headless is something our team needs to lean into? So what was that breaking point that had you jump right in? If you want to jump in first, Dave?

DAVE DICAMILLO: Sure. We adopted it very early on and I promise you it was because it was cool and it was on all the blogs and everyone wanted to do it and that’s probably why we first started. But the practical applications really started to come in with a lot of our clients having existing MarTech or existing video-player platforms or other software that they did not want to part with, and said, look, we’re happy to do this new headless approach.

We’ve heard a lot of good things about how we can manage data better, how we can be more flexible, from a UI perspective, how we can integrate new third-party products, in the future, more easily.

And I think we probably started really commercializing releases for our clients somewhere in 2019 and it’s been, again, the dominant architecture that we lead with, with a lot of our clients. But yeah, we’re very excited. We’re doing a number of WP Engine Atlas installs. We have one coming around the corner, in a couple of weeks, too, which is great. But yeah, that’s our initial journey with headless.

RAMI: So Adam, you mentioned you’re on the cusp of it. I love your take, since it might be a little bit more recent, of what’s starting to send you in that direction.

ADAM DAVEY: Well, with that particular client, they’d already– it’s often a complex decision, isn’t it, which CMS technology you’re going to use. But this particular client actually had an idea, exactly, as to how they’d set up and configure the CMS and how they manage their content. So it was an unusual one. We didn’t really need to take them on that journey. They decided on a headless CMS and they decided on a way of serving that content at the front end, across multi-channel.

But very often, that’s not the case. That was a technically-astute client. But very often, we have to– equally, we have to take people on a journey and I would say– we are also building another site, at the moment, where the client wants a WYSIWYG editor to be able to manage their content. So it really is all about use case.

And headless solves lots of problems and can slot in, as you said, David, slot into existing stacks. But there isn’t a one size fits all. It is about having a nuanced and detailed conversation with a client about requirements and different clients are at different stages of their maturity curve with digital and with headless and with CMSes of course. So it’s about meeting them, where they are, on that journey, really.

RAMI: Yes, Scott or Dennis, any thoughts to add to that as far as what– any indicators of when it might be time for folks that are just on the cusp of adopting headless, that you saw in y’all’s journey?

SCOTT JONES: Yeah, I think for us, it was similar to what Dave said, really. It was that we were reading about it. It was something that was out there. People seemed to be doing it and struggling with it. And actually, our first headless project was a rescue project and it was a nightmare, honestly. Honestly, it was a nightmare.

A client came to us with a really bad headless implementation, some very questionable technology choices. Every page took about– well, at least 30 seconds to load, which is mind blowing and that was our first foray into headless and it was messy, to say the least.

What the challenge for us has been, over a number of years with looking at headless, has being actually building the in-house expertise around JavaScript, essentially and that challenge, I think, was pushed along and helped along by the sort of rebuilding of WordPress into a react-based platform. And I think that’s really taken us on a journey.

So it’s actually come hand in hand, quite well for us, with bringing that expertise in, creating a better understanding with our developers, and then further in that journey into what we actually deliver to our clients as well.

DENNIS: Yeah, for our team, the driver is really our engineers and our developers and doing a retrospective on how do we continue to improve our agency, how do we continue to improve our process, they’re adamant about headless. For me, the analogy was thinking about my dad, who’s a mechanic, who works on cars five days a week, eight hours a day. When you do that for 10 years, 20 years, you really get to know what car brands, what engines you like to work on. That analogy is the same for me, for our engineers and they saw headless as an opportunity to be more efficient in the work and to drive better delivery.

So for us, it was driven by engineers as a way to be challengers and be innovative. We started to identify clients that we thought would be a good fit. We presented options to those clients and said, you have the option of going headless, where we think there’s improvement in the way that we develop your website, versus traditional and as clients started on boarding, we started that journey late in 2019 and have not looked back since.

RAMI: Thanks, gentlemen. So we all know and love WordPress. That’s why we’re here. Right? But we also are all very familiar with some limitations there and obviously, headless is a way to maintain the familiarity and the reliability of the WordPress backend for our content creators and our marketers, but also be able to address some of those limitations that WordPress presents.

So if anyone would have a particular use case or even a specific client project where you found that OK, we can’t abandon WordPress because of the needs and the requirements for the client, as far as content management is concerned, but we’re going to need to go headless because there are some limitations? I’d love just some real-life examples that get folks some inspiration when thinking about their potential projects, down the pipeline.

DAVE DICAMILLO: Sure, I can start, if you’d like.

RAMI: Thanks, Dave.

DAVE DICAMILLO: So the one that is around the bend for us, the Atlas project that’s coming up, they are a DMP. So they are a SAS-based provider. They have been on WordPress for years. However, they want to integrate a lot with their own software. So the architecture itself needed to really reflect both their desire to still be operational with WordPress, and being able to publish effectively– they don’t want to retrain the team– but they also wanted the deeper integrations into their own products and beyond.

So we’ve also been able to help them expand on what they can do with content on their site. So they were pretty nascent in what they were able to do prior to the redesign that’s coming. But using, even, the Atlas Content Modeler, and being able to provide a deeper, more robust content model for them to publish against, provide deeper personalization, provide that ability to talk to their customers in a more one-to-one way is going to be a real game changer for them.

So WordPress was a firm requirement going in and given some of those goals of the project, it just made complete sense that Atlas was the application. So hopefully, that helps.

RAMI: Dennis.

DENNIS: Yeah, for one of our clients, last year, we did this analysis of a number of different platforms, native headless platforms, WordPress with WP Engine, and really evaluated on two factors. Number one is going to be the features and functionality that the client needed out of the platform. Then number two, is really the total cost of ownership for the platform.

We went through this thorough analysis and ultimately landed on WordPress with WP Engine and Atlas as a solution from a cost perspective and the flexibility of the platform, and really, the familiarity with the marketing teams and by taking a component-based approach to our development process, we were able to effectively create a website that allowed the business user that’s already familiar with WordPress, did we already leverage the power of that platform, but be able to deploy components within their web page so that, as they’re building new landing pages or new experiences on their site, they don’t necessarily need to rely on a developer to deploy those new landing pages.

And we’ve seen a tremendous improvement in their delivery speed thereafter, from that one. So it was a very interesting project in the sense that– we spent a lot of time doing this upfront analysis. And then as soon as that analysis was done, it’s a very quick time to market and our clients have been very, very happy with the results.

RAMI: We like to hear it. Scott, Adam, any thoughts to add on this?

ADAM DAVEY: Yeah, just conversely– this is a slight deviation. But we’ve actually seen a client recently move away from headless, off– not with Atlas, of course, but like on a different platform. I won’t mention that platform. But they had such a bad time because they weren’t able to manage their content effectively. They’ve come back to Gutenberg, which is a really– we don’t want to see that happening.

But I think what we don’t want to do is force headless on people that aren’t ready for it. And it is a leap for marketing teams, I think and it isn’t right for everybody. But it also unlocks a whole load of powerful capabilities if you’re managing content, multichannel at scale. This is where headless and content modeling can really unlock a lot of opportunities for you so. Yeah.

But we don’t want to see people scared off by headless and we want to suggest solutions that are right for them. But I’ve seen a lot of benefits of headless, it is all down to use case and best fit.

RAMI: And you bring up a great point, of the responsibility to your client first, not too lead with the tech, to lead with what’s best for your client and that’s what we’re seeing– it’s an interesting inflection point for headless adoption, around what’s actually right for the client versus what is the new, bright, shiny tech. Scott, anything to add, examples that you’ve seen?

SCOTT JONES: I would just throw in though, and say, I think we’re all nodding when there are comments around headless being implemented badly in the past and that sort of thing and I think that is the important point, really, is do right by your client. That is what I would say on this, is, if you’re not ready, don’t do it.

So there’s always a little bit of– you need to put yourself out there and have a go if you’ve not done it before. But actually, WP Engine and the Atlas project have got plenty of tools, plenty of resources to be able to help, to go on that journey. I think when we all started out on this journey with headless, those tools didn’t exist and we were all building things like post previews from scratch, most likely, for most of us, and having to do things that weren’t in a platform, like headless now has.

So yeah, I think I would say, get involved in the WP Engine blueprint and have a try. But definitely, always anchor back to do right by your client and don’t be one of those deliverers who doesn’t deliver, so to speak, and ends up reversing the process back to back to Gutenberg again.

RAMI: Thanks, gentlemen. I think we covered, in a really thorough way, the benefits to the client of why you might recommend Atlas architecture. I’m interested to hear, what’s the benefits for your internal team, for your dev team, for your project managers, for your QA team? Where have you seen, taking this leadership role in headless adoption, seen the water rise for your internal teams?

DAVE DICAMILLO: Adam, you can start though.

ADAM DAVEY: I am a big believer in making sure everybody has buy in. I love what you said, David, about playing with shiny stuff and that’s what– I want to give developers the tools that they can do their best jobs with. But it’s also really important that the buy in comes in at every level of the business. So yeah, that the content managers are happy, but also, the stakeholders are happy at every level.

I’ve seen it where products have been sold and it hasn’t been quite right. There needs to be complete consensus and complete buy in. You need to take everybody with you on that journey around technology decisions.

And yeah, for me, again, it’s about a balance and it’s about making the right decisions for the right reasons for the business and the customer because we often– a lot of the decision making around headless is us being able to deliver a super-fast experience with a really lovely, clean, front end, that’s rich and intuitive, and it gets really nice Lighthouse scores and all of those good things, and that the developers love working with. So it’s a complete– it’s a mix. Getting all of those ingredients right is really important.

DAVE DICAMILLO: I’ll tell you who loves headless in our shop, it’s our designers, who feel a lot less limited. Our react engineers love it too. They’re just going crazy about what can we possibly do and how fast can we make this and the whole thing, everything you’re saying, Adam. But I think the real ability for us to extend some of the creativity beyond just what a normal publishing site would be, a normal content-driven site would be, I think, has been very eye opening for some of our team, even just beyond the technology folks.

I will also say that from a technology perspective, it definitely increases the time to deliver in some capacities. Testing, for us, has gone up, which is not a bad thing. It’s the right thing to do for the right product, at end of the day. But we have seen an increase about 15% to 20% in just that final polish before we go live, making sure all the connections are tied down.

DENNIS: Yeah, I think–

RAMI: That’s a good tip. That’s good insight, to when you’re looking at estimating, and your early in your first projects, make sure you’re taking that into consideration of, hey, that last 20%, the QA, the launch, and everything, know that could take a little bit longer when you’re first getting your first couple of projects off the ground. Sorry, Dennis. Go ahead.

DENNIS: No, I just wanted to build on that. In terms of looking at the operations of our Digital Experience team or the Development team, a few things come to mind. It really started to hit our stride in year number two, towards the end of year number two, in our headless journey.

And so objectively looking at the performance of their team, we actually saw the defect rate go down. So by decoupling the front end from the back end, our bugs and issues that come from deploying code on the back end was not affecting the front end and overall, we’re deploying cleaner, better code, which is fantastic to see.

To David’s point, the time to market was significantly faster than we’ve had in the past, again, because of that decouple architecture. So when a client needed a minor change in a front end, we didn’t have to schedule it with a back-end update for employment. Everything was moving faster there.

And then what’s also been interesting for us, as we think back about the last couple of years, is it’s changed the way we think about resourcing our team. So before, I really needed somebody that knew WordPress and could code on the front end. And we deal with a lot of e-commerce clients, as well, and know the e-commerce platform.

But now I’m able to hire a pure, react, front-end engineer that has no understanding of the back end, and get them productive within a matter of weeks, whereas in the past, we needed to develop some competency for the back-end platform. So that’s been really, really good to see, as an operator, for our team.

RAMI: What about you, Scott? Any thoughts on this?

SCOTT JONES: Yeah, I’m thinking– I’ve spoken to a few different agency founders on their approach to headless, and somewhat, have been similar to ours, which is actually, as the agency founder, I wanted to do headless and it wasn’t necessarily the rest of the team that were yet ready or engaged to go on that journey.

And speaking into Adam’s point, really, for us, that has been a journey of culture and of purpose and understanding our why, as a company. And I know that might sound really cliche. But that has been really important. If our team, especially our developers, understand the why of our business, as we go along, and they understand what are we actually trying to solve for the client, what are we actually trying to deliver– we want the most engaging, the most frustration-free experiences we can possibly deliver–

How do we do that and how does technology play a part in that has been a really interesting conversation and that has been the thing that’s taken them on the journey because yeah, we had some very firmly folded arms and grumpy faces when we first started talking about headless. And I’m sure you’ve all probably been in that situation as well and it has been making sure we’re having those conversations, making sure they understand the why, that has actually changed that dynamic for us very much.

RAMI: So keeping on the theme of velocity and efficiency and all those sexy, fun words, that actually are super important in the agency space, do you have an aha moment that you can share, whether it was a certain piece of technology, maybe it was a certain change in your process, maybe it was just using, literally, different vocabulary, that you were like, oh, gosh, if I had known this two years ago, we’d have been more profitable, we’d have worked faster, people would have been happier?

Then maybe you could share, with folks– an anecdote that you could share with folks that are a little earlier in their headless adoption journey. I’m not asking for trade secrets, just a light-bulb moment, perhaps.

SCOTT JONES: I’ll just jump back in on my point, if that’s OK. For me– and I’ve got a more client-facing role than a technical role and so I’m always thinking about business case and how to build a business case and I’m obviously thinking about that externally. What I wasn’t necessarily doing was thinking about that internally and bringing that same business case back to our developers, back to our designers, project managers, to our team.

Once they started to see some of the reasons that clients would need headless– so for example, being able to store maps natively, on a mobile device. You might be halfway up a mountain. You need that map stored natively. You’re not really going to be able to do that with monolithic, I guess, headless, and, sorry– WordPress– and showing some of those use cases.

I think they were the– I get why a client would want this, I get why a client would actually want to serve one base of content to two different front ends. Actually showing them some of that has been the aha stuff, for us, alongside the cultural stuff.

RAMI: What about you, Adam?

ADAM DAVEY: Yeah, just jumping in there, I guess one of my ahas was– we work with all kinds of clients, with all kinds of complex business needs. But what clients will often lean on is a solution that apparently does everything for them, like an all-in-one suite, which often can be really, really powerful for them. But that Swiss army knife, they probably end up only using a blade or two out of the whole kit and that’s what we see.

So the aha moment, for me, is clients are now thinking about buying one part of a stack that does something really, really well, and it’s the best at doing that one thing really well, and then just layering up your stack with equally– with other components that do their job really, really well.

So the aha, for me, is, I guess, witnessing clients, over the last few years, and actually, the pivot, the shift towards buying what you need, something that’s best in class, that delivers really well on what it’s supposed to do.

Like I say, suites and DXPs do have their place. But we’re increasingly seeing headless being slotted in as a part of a wider ecosystem of technologies that just does, really, one job excellently. I think that’s been the last two years. That’s the change we’ve seen.

DAVE DICAMILLO: Yeah, I agree and I think that the explosion of MarTech tools, and being able to take the best in class, and integrate it, not just now, but off into the future, is really the reason to select headless.

Those DXPs, yeah, they’re great. But you’re right. Most clients of ours use 10%, 20% of what they’re paying for and they’re not getting the value that, if they actually worked with these smaller, MarTech providers, that they actually get the support that they need. They can actually use the features better. But yeah, one thing that we try to coach a lot of our clients on is that it’s not about getting live with headless. It’s about looking at the future of what you want to do in the first 12 months.

When you’re launching a headless site, at least in our world, it is more about the MarTech stack that we’re putting in play than just the CMS. We’re trying to enable some different features, personalization, ABM tools, you name it. All that stuff comes into play.

And we want to strip back clients to get to a point where they’re launch ready, and then look at, what does that first 12 months look like? They’re going to continue to grow. We like to say, the first day of the website, it’s its worst day. You’re there to take the website and grow it from that point and if you’re thinking longer term, thinking what that first launch point looks like, plus 12 months, I think that really solidifies a good case for headless, especially when you’re not DXP-related, like Adam’s saying.

RAMI: Any thoughts on that one, Dennis?

DENNIS: I think the aha moment, for us, was as we actually saw organic performance improve, three or four months after launching headless site. And that was when– starting to promote that. This is really happening and this is part of why we’re doing what we’re doing and seeing that play out has been pretty powerful for us, as a group.

And that’s why I think, similar to David, the majority of our bills, at this point, now, are headless because from the perspective of being a performance-marketing agency, our job is to position the website to be a tool for our marketing partners within the agency and building them a website that can form, it makes their job easier.

RAMI: So we’ve talked a lot about buy in, internally, and the reasons why, obviously, your internal teams are excited to work on headless. Question for y’all that are actually involved in that upfront, proposal, sales-pitching phase with prospects and current clients.

What’s the magic bullet that gets their attention? Is it performance? Is it the flexibility? Just a little coaching, for other folks, joining us, that are starting or pitching outlets, what are you seeing that, really, your clients or prospective clients are holding on to, and really pushing them over the edge?

Because we know adopting new technology, especially for a traditional business, is scary. They’re risk averse. Switching can be very expensive. So what are you finding that the decision makers, when you’re pitching a headless architecture, are really grabbing their attention?

ADAM DAVEY: Yeah, I can jump in here if need be. The one thing we use, time and time again, are actual products demos because without showing clients what they’re buying and how those platforms work, it’s pointless. It’s just words. So we need to actually tangibly demonstrate how headless works.

And there is fear around this. So what we need to do is answer all the questions, show the use cases, explain how the content is modeled and managed and how those workflow approvals, or whatever those features we’re using within the CMS, actually work. Nothing beats a demo because otherwise, it’s just too abstract. We need to actually show, demonstrate, what the capabilities and the power of the platform is. So I would say that’s the most powerful tool that we have up our sleeves.

DAVE DICAMILLO: Yeah, I’m going to piggyback on that. But the number-one question we get is, what’s the day in the life? And this is a CMS question in general. Any time someone’s moving to a new platform, it’s, what’s my life going to be like?

We spend a lot of time, in the pitch process, actually educating about, just high level, what do these different architectures mean? Pros, cons, what are the different players in the space, all that kind of stuff. But we never make a decision in the pitch. It’s always about getting under the hood, with the client, to Adam’s point, doing demos, bringing in the partners, having them pitch their own wares.

It’s one thing to say, oh, the agency told us so. But it’s another thing to have software makers and the folks come in to the table and say, well, here’s why we’re best.

We have a very long decision-making process that we coach our clients through, which is based on key business criteria and we want to put up CMS that are the best in their own classes, headless or coupled, and let them stand out about, well, what does this mean to your business? Is it going to actually affect it?

Here’s a raw score. Don’t just take Code and Theory’s advice. Here is an output in a number that says which one is better for your business and then make an informed decision about which way you want to go.

DENNIS: For us, when we start a conversation around whether or not headless is the right option for our client, being able to pull up one of our websites that we built, and in front of the client, live, run a Lighthouse score, on that website and show them the score. That’s an immediate all right, tell me more and then we go down this path of, what is our tech stock or whatnot.

But for us, that’s always been the biggest conversation starter in any sales opportunity, is to show them what is possible and when you’re getting green scores on Lighthouse, that is near impossible on these other platforms because of a coupled architecture, it really is a powerful story to tell.

SCOTT JONES: Yeah, I agree. I agree with all of those answers. I think for us, it feels like we’re selling FOMO a little bit, really, that fear of missing out approach and so aside from the obvious performance and security benefits– I don’t know if it’s the same for you guys, but we’ve noticed that actually, doing an audit on our client base, we realized our best clients are actually quite strong on technology and quite strong on user experience. They have in-house developers or in-house UX teams or whatever that looks like. They actually understand.

And so they’ve done a bit of research into this themselves. They understand a bit of this. They already have the obvious. The thing that tends to be missing from the mindset is actually selling the future and thinking about, from a development perspective, all of the developers, programmers, that are going into boot camps now– I’m generalizing, here– but they’re learning JavaScript and so if you’re still working back in the day or as we currently are now, you’re not quite thinking about where the market’s going to go in the future.

And I think we’ve all seen– JavaScript developers have been quite expensive, reactive developers, in particular. They’ve been very in demand. That’s going to change because every new developer is learning this technology and this progressive set of frameworks.

That is the important thing in a business case, that actually are pointing forward, to particularly, the technology-minded companies, that this is a consideration for you. If you build something now, what’s your development team going to look like in three, four, five years? What’s our team going to look like in that time?

If you went to another agency and didn’t work with us, what would that team look like? how much would you struggle to get the resource you need, based on what we’ve built? And so yeah, I’m looking forward and trying to switch the mindset a little bit there.

RAMI: Scott, you took my last question–

SCOTT JONES: Oh, sorry.

RAMI: –right away for me, which is– it’s OK. It’s all good. I would imagine folks that attended– I know my first DE{CODE], and folks that, this is their third, fourth, fifth year they’re joining us, I think that the weight that headless WordPress and Atlas is carried in our agenda has continued to increase and grow. Three years ago, I don’t know that we had a full track developed to it and now we do.

So as we wrap up, what I would love, just to get your magic. If you’re looking in the crystal ball and looking ahead, as you are future proofing what your headless WordPress practice looks like, what’s on your radar right now? Maybe you’re not spending a lot of time on it. But what’s in the back of your head, that this is something that’s coming down the pipe, that we’ve got to be prepared for, regarding headless architecture? I’ll start with you, Dennis. First one up.

DENNIS: Oh, goodness. The pressure’s on. So as you think about the future– and I have a lot of these conversations internally, with our team– I think a world of low code, no code is very real, and especially as a traditional systems integrator and SI team that historically done backend integrations. So as we think about that, and we think about how the composition of the team will evolve, absolutely, design is a core competency. Strategy is a core competency.

And then in front-end development or with ArcGIS development, I think, is going to become a core competency and we’re already seeing this shift from heavy back-end to heavy front-end, heavy-strategy team members as well. So we’re positioning our team that way. We think that’s going to be the future. And we’re going to scale and adjust as things evolve.

RAMI: What do you think, Adam?

ADAM DAVEY: For me, I think composable is the way forward. That that’s where it’s at and the ability for all these different components to integrate with each other and the interoperability of these different platforms is really important. So I think that that ability to communicate and offer best-in-class, best-in-breed solution with a stack like that, that’s going to– these platforms are only going to be more and more powerful in that sense.

So the ability for these things to integrate together cleanly and for freeing up developers to, as you were saying, Dave and Dennis, just really do their best work and for the designers to do their best work, for me, it’s all about composable, I think, particularly with headless CMS, is how they pair nicely and play nicely with that, as you said, David, the MarTech stack, but particularly e-commerce.

That’s where we’re seeing most of the opportunity at the moment and the biggest conversations that we have are really around headless commerce solutions, coupled with headless CMS solutions and I think that ability to integrate and couple those systems together is going to be really, really key.

DAVE DICAMILLO: Yeah, you took the one that I was going to say, as well. Composable web is– new technologies spur new innovations and composable web’s the thing that’s being built on top of the headless world, which is, how do I orchestrate everything? How do I make this all easy for my team to use?

I have seven different pieces of MarTech and it’s all over the place. But the data sets can all be integrated. And they can all be used in one tool. It’s actually the number-one thing we’ve seen come back from clients, six months, a year after. Hey, we love it. It’s great. But we need to be more efficient and what are the tools out there, the stack bits of the world and everything else, that’s coming around?

And it’s doing– it’s the next level of headless integrations. So I totally agree that that’s where this is going, not downplaying anything with low-code, no-code. We’re seeing all that stuff too. But, yeah.

RAMI: Gentleman, thank you so much for being so gracious and sharing so much with us. This has been super valuable. I know I learned a lot and I think this is a great foundation for our partners and developers out there, that are just now stepping into headless, as well as those that have been on a similar headless journey as your four agencies and are three, four years in.

I appreciate everybody joining us today and I hope you enjoy the rest of your time at DE{CODE}. Have a good one.