The relationship of technical debt and headless commerce

If you’ve been part of a tech stack decision, you’ve likely been asked to help assess the possibility of technical debt while considering a new tool. The term technical debt is commonplace in any IT department, but it’s not always used in the way it was originally intended.

“Technical debt is a metaphorical framework for thinking about the cruft that needs refactoring after a development team expedites the production of software,” is the definition used by tech debt company, Stepsize.

In layman's terms, it’s a metaphor that compares borrowing money (debt) to the side effects of making a hurried software decision and incurring codebase deficiencies, or cruft.

Table of Contents

Technical Debt in Headless Commerce

Build vs. Buy Debate

Monolithic Services vs. Microservices

It’s not always possible to completely avoid technical debt, and in some cases it may even be strategic, just as borrowing money can be. And just like borrowing money, it’s a delicate and sometimes risky decision that should not be taken lightly.

Headless commerce solutions are not immune to the impact on technical debt. As CTOs and IT teams consider when and how to embrace this new wave of innovation, they’re faced with technical debt considerations as they compare products, evaluate their needs, and make predictions about the future of their industry and business.

This blog explores types of technical debt, how it pertains to headless commerce and gives Nacelle’s perspective in the context of our headless commerce platform.

One of the most popular ways to categorize technical debt is by using Martin Fowler’s Technical Debt Quadrant. Fowler worked with Ward Cunningham, the man who coined the term, and 15 other authors to pen the Manifesto for Agile Software Development. The quadrant includes four scenarios for technical debt:

• Reckless and Deliberate

• Reckless and Inadvertent

• Prudent and Deliberate

• Prudent and Inadvertent

Hackernoon simplifies it further with three main types of technical debt:

1. Deliberate Technical Debt - Sometimes when a team needs to get something to market quickly, there’s an informed understanding and acceptance that the process will incur a level of debt.

2. Accidental/Outdated Design Technical Debt - This category comes down to engineers attempting to “future-proof” their codebase. “A good original design will often be easier to refactor incrementally, but sometimes you may have to bite the bullet and do a more significant refactor,” says Hackernoon.

3. Bit Rot Technical Debt - This type of debt is all about a component or system breaking down over time. It’s more likely to occur if the original designers are no longer available for maintenance or input, and new designers don’t fully understand the work of their predecessors.

Both takes on the types of technical debt have common themes: Sometimes technical debt is deliberate or can’t be avoided, and sometimes it’s unintentional. Regardless, at tech stack decision time, it’s important to try and be mindful how today’s decisions might realistically impact tomorrow.

Technical debt in headless commerce

There are key themes to consider when assessing a headless commerce solution that could factor into technical debt:

• Flexibility: Flexibility can apply to many things, but in this context we’re talking about solutions molding to your company’s operations, not the other way around. An ideal solution will not have you upending your current tech stack or making disruptive changes in order to get your new tool to function properly for your business. The right solution should seamlessly fit into your tool box, or at the very least make few waves.

• Optionality: The sister benefit to flexibility, optionality is a nod to best-of-breed strategy. An impressive headless commerce tool will allow you to freely choose the other tools in your tech stack that you want to use and that make the most sense to your eCommerce brand. Each tool is an entirely different entity run by different companies. Typically these tools are best-in-class because they’re expertly dedicated to one function, rather than a “Jack of all trades, master of none” scenario.

• Scalability: How will your company look in 3-5 years? What will be the landscape for your industry and eCommerce overall? Of course you can only make educated decisions that you think will be relevant and beneficial long term. But you can also “future-proof” your business by seeking investments that will scale easily with your growth and evolution. Such tools reduce the required guesswork of predicting debt because the solution is fluid enough to grow with you and reflect the changing needs of your industry.

The build vs. buy debate

Another consideration when going headless whether or not you’re going to build or buy your own solution. It’s almost never fruitful to build your own software. A “buy it, then bend it” approach is typically always the best avenue. The decision to build your own headless architecture is riddled with opportunity for technical debt.

The build itself is expensive and maintenance costs are constantly underestimated. Additionally, it’s unlikely that your build can compete with equivalent products on the market that are run by companies solely dedicated to that product’s functionality and success. It can also be very difficult to outpace competitors, let alone keep pace, when your build is hogging resources you didn't account for.

Building your own software can be the right choice if there’s not a solution on the market that can fulfill your needs, or you have such a unique IP that there’s value in keeping the intellectual property of the build in-house.

Typically large technology investments will allow a level of customization that can fit your exact needs and still differentiate your brand from competitors, hence the “buy and bend” ideology.

Monolithic services vs. microservices

This conversation is around the headless commerce solutions you may be comparing. Monolithic services are built as a single unit, usually as one codebase. Conversely, microservice architecture is a curation of small services, each with its own codebase. There are pros and cons to each, as well as technical debt considerations.

Monolithic

• Pros: If your entire tech stack is run from one resource, every aspect is almost guaranteed to “talk” to each other and work cohesively. Using one service can also mean less operational overhead for you and your team. Additionally, up front costs could be less.

• Cons: These tools are often completely wedded to each other and it can be difficult to introduce outside technologies to your tech stack or decouple the monolithic solution to pick and choose the aspects that suit your needs. It can also be harder to understand, because the infrastructure can be more complicated when there are so many dependencies at stake.

Microservices

• Pros: As mentioned earlier when discussing best-of-breed strategy, if your services are separate entities they’re more likely to be the “best” at their respective duties. When your tech stack is decoupled, it’s easy to both drop and introduce tools without affecting the others. With separate technologies, there’s less room for mistakes that could take down your whole system. Your tech stack is still connected, but an issue with one tool will not touch the codebase of another.

• Cons: Most best-of-breed tools are designed to work cohesively with others, but it’s not always the case and something that should be well-researched ahead of time. Also with this approach, there will be more operational overhead and many disparate systems to manage.

These considerations should be at the heart of your headless commerce technical debt conversations, because the decision between microservices and monolithic services might impact not only the amount of technical debt you incur, but the type, as discussed in the Technical Debt Quadrant.

Evaluating the future of eCommerce and your company

Nobody can predict the future, but in the spirit of making an educated technical debt decision, there are a couple trends that should be top of mind now and in the future for your brand.

• Automation: According to Gartner, one way to limit the accrual of technical debt is to improve the amount of automation gleaned from your tech stack. Through 2023, technology and operations leaders who actively manage and reduce technical debt will achieve at least 50% faster service delivery times. Look for tech stack tools that will help you automate your redundant processes and free up your time for more imperative tasks.

• Data: Data is going to be the lifeblood of most tech stack solutions now and in the future. Today, software often comes with a data component, be it data collection or data analysis. The more data you have the better business decisions you can make, so be sure to start looking for data capabilities in the tools you’re evaluating now.

• Strong Communication: Transparency has become so important to customers, both about their specific orders and as a portal to your brand. In order to thrive in the D2C landscape, your business needs to get to a place where customers feel heard and valued. Technology can help break any communication barriers your team might be having with your customers.

• Delightful Experiences: This is here, and here to stay. Online shoppers are on mobile devices and they don’t have the patience for slow, under-performing websites. Slow page load speeds on any device are impacting your eCommerce KPIs including conversion rate and average order value (AOV). Do everything you can to provide a positive experience to keep your customers scrolling, clicking and shopping.

• Post-pandemic User Behavior: Joe Belliini from Supply Chain Beyond said it best, “buying behaviors which may have taken a decade to evolve in normal circumstances have been forced front-and-center by virus-related restrictions.” The eCom behavioral changes of 10 years have been squeezed into one, and technology is the only hope to scale effectively while meeting shoppers’ demands and expectations. From the impact on the supply chain to webstore traffic and mobile-first considerations, every investment moving forward needs to be seen through this lens.

How Nacelle reduces technical debt risk

Like any tech tool, merchants considering our platform are wary of technical debt from new investments. Fortunately, our product is configured to reduce this risk.

We’re a headless commerce platform that acts as the “glue” that holds your disparate tech stack solutions together, and often enables them to function more harmoniously. By nature, we are best-of-breed, not an all-in-one solution.

Being best-of-breed allows for flexibility, optionality and ease of scalability for your business. Most merchants we talk to have graduated from all-in-one solutions because they’re inflexible and likely require risky migrations or overhauls. Plus, those inflexible solutions have a hard time scaling with your business. Nacelle helps you harness your best-of-breed microservices while giving your development team the convenience of one API to work with.

For more on taking your tech stack headless, read our Guide.