Build vs Buy: Commerce Storefront

In my earlier article, I discussed the first step to a successful headless commerce storefront— hiring a good frontend developer. Once you have that person in place, your expert can help you decide whether to build or buy a headless commerce storefront.

The Project Triangle

The decision to build or buy should go through the project triangle lens. 

1. Cost - Total Cost of Ownership (TCO)
2. Time - Time to Market
3. Scope - Business Requirements

Total Cost of Ownership (TCO)

General Principle: Buying is cheaper in the long term, while leasing is cheaper in the short term.

Buying a storefront (otherwise known as FEaaS) is no different to leasing a physical asset. Let’s take three physical items as examples:

1. House - Do you prefer to own a house or rent?
2. Car - Do you prefer to own a car or lease every three years? 
3. Mobile Phone - Do you prefer to own the phone outright or pay monthly?

Your answer to those questions often determines your default choice on what you think is better/cheaper. Own or lease?

Building from scratch (owning) is cheaper in the long run, but it comes with more maintenance headaches. I’ve read anecdotal evidence showing that owning a storefront costs more, but that’s an exception, not the rule. TCO for FEaaS is generally more expensive.

What about limited budgets?

TCO is not the only cost consideration. While most prefer to buy a house, not everyone can afford it. Storefronts are no different. Not every retailer can afford the upfront cost to build a storefront. If your goals are short term, FEaaS can allow you to use headless solutions on a limited budget.

Time to Market

General Principle: Building from ready-made components is quicker than starting from raw materials, but applying customisation to ready-made components will take longer.

Let’s take furniture as an example - Assembling flatpack IKEA wardrobes are often quicker than getting a carpenter to join together a built-in closet. However, extending IKEA furniture is less ideal than extending bespoke furniture. The same principle applies to building software. 

I was once asked to build a checkout from scratch, and it took me six months to complete. I refactored/redesigned it a few years later, and that took only two months. Reason? I reused the existing foundation.

Buying a storefront (FEaaS) is often quicker to deliver initially since you have a working foundation.

What about storefront customisations?

On another occasion, I added customisation on top of a ready-made storefront. It was OK until I had to integrate APIs specific to my client’s organisation. The integration took 4x times longer since I had to work around the architecture to ensure future upgradeability.

The downside of FEaaS is heavy customisation limitations. This usually happens when you have a use case that requires core code changes—for example, deeper performance optimisations, unsupported product integrations and cutting edge technology adoptions.

Business Requirements

General Principle: The secret to investing is to figure out the value of something – and then pay a lot less. (Joel Greenblatt)

Product features and roadmap offered by FEaaS platforms is the only deal maker or breaker. 

Here are a few questions worth asking:

• How much of your business requirements are covered by the FEaaS feature list? 
• How good is the FEaaS coverage for non-functional requirements?
• What does the FEaaS product roadmap look like? Is it in line with your business roadmap?
• How many of those FEaaS claims are verified by your frontend expert?

As a general rule, FEaaS solutions are more complex to build than custom software, since generic technical solutions are required to serve multiple tenants. Therefore, I don’t often recommend a FEaaS solution until they reach mid-to-peak maturity. That means they have to be a few years old with a visibly strong engineering team.

FEaaS platforms are new. While adopting FEaaS is a reversible decision for small to medium businesses, they can be a risk for larger organisations with bigger stakes.

Larger organisations should be a bit more cautious when it comes to FEaaS adoption. The rate of failure (or being successfully sold) for young product organisations are high. I am familiar with at least one FEaaS organisation sold recently and two other FEaaS-like solutions that fizzled out.

What about business-specific requirements?

When considering the frontend, it’s worth understanding what part of the frontend can be productised. For example, I will always pay for cloud infrastructure over self-hosting to take advantage of economies of scale. Infrastructure requirements for organisations are the same everywhere. However, I don’t think we can say the same for frontend requirements. Customisation is always necessary for frontend. Therefore, it's always wise to verify FEaaS claims with your frontend expert.

Hidden Consideration: Developer Experience 

General Principle: Risk comes from not knowing what you’re doing. (Warren Buffet)

Knowing all the variables can help you decide better; DeveloperExperience.io has this helpful diagram.

Here’s a final thought I want you to consider; the emotional cost for developers, otherwise known as developer experience (DX), is a significant driver for the headless movement.

Many brands and retailers are late adopters of API technology and JS frameworks compared to pure-play e-commerce (such as Asos, Boohoo, Amazon). However, engineering across industries are encouraging organisations to adopt more enjoyable DX innovations. In reality, much of headless adoption is not about business results but process change to improve DX. If you wait long enough, your suite will adapt headless themselves.

Understanding DX as a hidden consideration will allow you to have a clearer picture in decision making. Sometimes, waiting might be the best strategy if your business goals are not about improving customer experience or brand differentiation.

Final Thoughts

In summary, buying a storefront (FEaaS) is ideal for smaller initiatives. Perhaps PoCs, small-to-midsize retailers, micro-commerce or anything that requires fast time to market. On the other hand, building from scratch is ideal for larger organisations with higher stakes and brands & retailers who require more brand differentiation & customisation.

These are just general principles. You’ll need to weigh up the risk vs gain in your specific context with your frontend expert. Of course, remember that DX is also a hidden consideration that should inform your decision.

Technical business decisions can be difficult when trying to balance bottom-line results and the changing technology landscape. This is why it's important to hire a good frontend developer who also cares about business results before you move to headless.

To quote an old Hebrew proverb,

Without counsel plans fail, but with many advisers they succeed.

If you want to talk about this further tailored to your specific context, send me a message. Always happy to help.

Alternatively, weigh in on the conversation— use the emojis or drop a comment below. What do you think? Should brands and retailers build or buy a storefront?