Is Headless the Right Question?

Everyone is asking themselves; should we be going headless or not? But is that the right question to be asking? It all comes down to a series of factors; your business goals and your problems alongside a host of other contextual information, you could be trying to build a community around your brand or provide a customisable experience. Perhaps you struggle with internal organisation and your agility, but before you ask, is headless the best fit for you we want to take a step back and ask what is the right question for you as a business? Is it headless? Or could it be something else?

In order to discover the correct question, it’s important to think about why you would want to go headless, not just the feature or capability you want but rather what causes you to want it, what do you struggle with in the day to day?

Why Not Headless?

Headless is almost synonymous with ‘frontend’ to many, in short it means you can make the frontend do whatever you want it to do but what it doesn’t address is what does the business need to be able to do? What kind of tooling do they need to operate efficiently? Ultimately most businesses’ top priority is the ability to manipulate the user experience on the frontend with a greater degree of ease and freedom.

However, with headless at the end of the day you still have to spend the time and resources developing the code and making templates you need, anything you want to make has development time. On the other hand, the right composable toolset and architecture with a head (such as a unified commerce platform) often has better capabilities and better tooling to make those kinds of changes with much less or in some cases no coding and dev work even if your overall freedom is potentially restricted to a greater degree. This restriction can be offset by the fact that you have enough flexibility and power to make the changes you want and test its ROI without waiting through potentially expensive development time to see if your ideas work as intended, so if you’re unsure of the ROI involved in your frontend changes, there might be other questions to ask yourself and other avenues to explore before jumping into a headless platform, particularly if your current platform has a tightly coupled front and backend.

Many people want to get rid of tech debt, become more agile and separate front-back end, however once they understand the costs from a technology and DevOps perspective, they start to become prohibitive with the actual development as in reality they haven’t got the budget or the organisational capacity to deal with the associated demands of headless despite being enamoured with the concepts and ideas behind the implementation.

What are you trying to solve?

What business issue you’re trying to solve will always be at the heart of a platform change. If your problems are rooted in your agility, organisational structure or reference architecture then the answer is probably yes, you should go with a solution based on composable technology and underpinned with MACH architecture, but you need to make sure headless makes sense for your business, for example, you might not have the business architecture to support headless, you might not have the IT development capability or the business management organisation necessary, the team might be too small etc.  Headless works excellently for some but it’s not the only answer to a potential problem.

Maybe, as many others do, you struggle with speed, specifically the speed of frontend, but what’s stopping you from achieving the frontend speed you want? There may be code enhancements you can outsource in order to reach those speeds you want, but conversely you might require response time in the milliseconds if this is the case then it’s likely that headless is the question you should be asking yourself, that said there are still other alternatives to an improved frontend speed.

If you’re looking not for speed of frontend but rather the speed to innovate in rapid iterations then you need to work out what it is that’s slowing you down, a typical example of this is technical debt, maybe you have so much technical debt that you can only do new build releases every 3-5 months due to your internal processes and the vast amount of end-to-end testing.

If you do deal with these constraints as a business, then you can hire help for the code changes but if it’s the release management aspect you’re struggling with then you’re likely heading down the right path asking about headless, however there are other ways to address your technical debt working within systems that have a head but still embrace composable architecture. The difficult part is working out your strategy and how you move away from that type of technical debt; despite how it’s portrayed, it’s often not as simple as simply unplugging your current platform and plugging in a brand-new full stack of composable architecture.  

Migrating to a full stack composable MACH solution is varyingly complex based on the business. You can’t just unplug and then plug in a different solution, if you’re on a traditional monolith you might be looking at all the costs of implementing a new headless platform alongside the costs of maintaining your current monolith with a project which can likely take many months. Or you could be so far into a project that it’s more worthwhile to build a workaround rather than switch platform. The real benefit however from a fully composable tech stack comes long-term.

If on your platform and in your future roadmap you’re fully composable and you want to switch from one composable platform to another it would most likely be more like 12 weeks as opposed to a 12-month or more project of shifting from a traditional monolith, this is because you only need to focus on the APIs for the platform and ensure the same or better functionality. This is where a large amount of the value you receive from a headless platform lies, it makes future shifts onto other composable and headless platforms far easier and far faster.

So, while headless is the right question to be asking yourself for some scenarios, it’s not the be all and end all for composable or for increased flexibility, other avenues exist for similar problems and unified commerce platforms allow a very good degree of functionality for what the business might need to be able to do without going fully headless.

Your Strategy

When examining your strategy for moving away from the type of technical debt mentioned above and deciding what questions to ask yourself it’s important to take a top-down view; take the example of Rubik’s cube. To solve it you need a view of all the problems in all the different dimensions in order to solve the overall problem, very few people can solve a Rubik’s cube with a single lookover of its configuration, in most cases you need to get the cube to a state where you’ve mapped out enough individual problems over time that you can then accelerate into rapid problem solving as certain areas are now more aligned which makes further organisation easier. Understanding your business well enough that you can prioritise and sort problems in the correct order to reach a stage where you can visualise the roadmap you need to proceed with rapid iterative problem solving.

Need help visualizing your roadmap? Interested in a digital maturity assessment? Speak to us today!