What makes e-commerce apps so hard to build?

E-commerce is a cornerstone of the internet economy. There are millions of e-commerce applications out there and more being built every day. For such a common type of application, they are famously hard to get right.

In this post I'll outline some of the factors that make e-commerce applications the final boss of web apps, and then discuss some of the solutions.

The Problems

If you want to build an e-commerce app, you need to think about:

1. SEO. This is critical. Thus you need to carefully consider SSR vs SSG, caching, invalidation, url design, redirects.
2. Performance. Long loading times or sluggish response to input will drive away customers and impact SEO (see 1). Bundles need to be kept lean. And remember, marketing plans to later add 3MB of JS via Google Tag Manager 🙃.
3. You have an impatient audience who can go elsewhere. This is not some intranet app that users are obliged to use. You need to win them over with a superior user experience.
4. You are dealing with financial transactions. Bugs can be very consequential! A rounding error on a high-traffic site can get ugly 😬.
5. Storefront apps are complex. Beyond basic product list/detail/checkout, you have search, filtering, wishlists, auth + accounts, gift cards, promotions, taxes, shipping, and on and on.
6. Integrations. A typical e-commerce app will minimally integrate with one or more payment providers, shipping providers, then maybe taxes, recommendations, CMS, reviews, emails etc.
7. Legacy systems. Many businesses run on tech that cannot easily be changed. So your shiny new app will have to talk via SOAP or CSV files or do daily data imports from some server in head office.
8. The messy real world. Payments will fail, customers will call to change an order, refund or return. Stock levels will get out of sync with the warehouse. It's a concatenation of edge cases.
9. Scaling. Black Friday/Cyber Monday should not take down your website! But you also don't want to pay for a maxed-out server all year round.
10. Internationalization. Are you selling in multiple countries? OK now you need to think about multiple languages, multiple currencies and exchange rates, display formats and (worst of all) multiple sets of tax rules.
11. Taxes. I know I already just mentioned them, but getting tax compliance right is so hard that it deserves its own bullet point.
12. A long shelf life. The typical e-commerce application needs to be operational for many years, even a decade or more. Especially when a lot of work has been done to integrate with existing systems, the cost of migrating to an entirely new platform is high. Therefore they need to be able to adapt to tomorrow's technology landscape.

The Solutions

There is no single solution to all of these problems. Rather, there are a number of approaches which offer different trade-offs. Broadly, we can think of three axes of solution:

1. SaaS vs Framework
2. Monolithic vs Headless
3. Proprietary vs Open source

SaaS vs Framework

SaaS platforms take care of the operational issues, at least in theory. Even giants like Shopify can still have outages but in general they deal with traffic spikes well and let you forget about servers. Moreover, SaaS platforms free your team from needing to worry about upgrades and maintenance headaches.

With widespread adoption, the leading SaaS platforms include much of the typical functionality required by most businesses, thereby cutting down the amount of custom development needed. For smaller and simpler use-cases, they can be a complete solution, and there are often existing integrations for most popular services for payments, shipping, taxes etc.

Where they can fall down is when it comes to very particular business requirements. Remember those csv imports from that one supplier? Or the custom order flow demanded by the business model? You can end up having to write a lot of custom code, sometimes fighting against the platform. Or else cobbling together a Rube Goldberg collection of third-party extensions which becomes expensive in terms of money and maintenance.

SaaS examples: Shopify, BigCommerce, Commercetools, Swell

E-commerce frameworks provide the building blocks for developers to create completely custom applications. Those tricky integrations with back-office systems and those specialized workflows can be custom built by extending the core functionality of the framework.

Frameworks typically require at least some custom implementation work, potentially driving up initial costs. Furthermore they need to be hosted, meaning that you are responsible for operations and keeping your store live over Black Friday. On the other hand, savings can be had in ongoing costs, as many frameworks do not require a yearly license to operate.

Framework examples: Magento, Saleor, Vendure, WooCommerce, Shopware

Monolith vs Headless

Monoliths refer to applications in which the front-end storefront part is an inseparable part of the backend platform. Typically, the same platform will be generating the storefront based on a templating or theme system. Monolithic architecture has been around for a long time and is the most common way of building e-commerce apps.
Monolith examples: Shopify, Magento, WooCommerce.

Headless platforms, on the other hand, do not handle the storefront at all. Rather, they provide APIs (typically REST or GraphQL) which expose all e-commerce functionality, allowing a storefront to be created to the exact needs of the business, using the latest technologies.

Headless architecture removes the technological lock-in of monolithic solutions, de-coupling the storefront app(s) from the commerce backend. This can allow merchants to take full advantage of the latest techniques to produce fast websites with a great user experience. It also allows a single backend to power web, mobile, point-of-sale and other apps simultaneously.

From a developer perspective, headless frees up teams to use the technologies and workflows that suit them best. No more limitations of a restrictive theme system. No more being bound to non-optimal processes imposed by the backend.

The major challenge with headless is that you get no storefront out of the box. Presenting raw JSON to customers won't fly! Building a storefront is a large undertaking, so the up-from implementation cost will be higher than with monolithic solutions which include a storefront.

To mitigate this factor, there are an increasing number of storefront projects which have done all the hard work of implementing a modern commerce front end app, allowing you to plug them in to the headless backend of your choice. Examples include Vue Storefront and Vercel's Next.js Commerce.

In recent years, headless architecture has been gaining a lot of interest to the point that many of the traditionally monolithic solutions have either added support for headless (Shopify, Magento) or have completely shifted focus.

Headless examples: Commercetools, Swell, Vendure, Crystallize

Proprietary vs Open Source

Proprietary platforms do not make their code available, or make it available only under a commercial license. All of the SaaS platforms fall under this category, and there are also some proprietary frameworks - especially at the higher end of the market.

Open source projects have long played a major role in e-commerce. Especially at the mid-market, open source solutions like WooCommerce and Magento still dominate.

The advantages of open source platforms include pricing, a potentially larger developer community (and thus hiring pool), the ability to modify the code to fix issues and some degree of protection from vendor lock-in.

The trade-offs with open source solutions are the same as with frameworks in general, as open source solutions are typically self-hosted frameworks. Proprietary platforms may also be able to offer better customer support and things like service level agreements, which are not always available for open-source products.

Many open source projects also offer a hosted version, which combines some of the strengths of SaaS with the control offered by frameworks.

Vendure

I started building Vendure as an attempt to solve the particular combination of problems that our business had encountered. Vendure is an open-source headless commerce framework. Now that we've covered each of these terms, you should have an appreciation of the problems it is solving and the trade-offs that it makes.

It handles all typical e-commerce functionality (and we spent a very long time getting taxes right!), whilst providing extension points which allow virtually any custom functionality to be added.

It embraces modern tooling, including TypeScript and GraphQL, and is built on one of the most popular and widely-used Node.js frameworks - NestJS. A primary goal of Vendure is to provide an outstanding developer experience which allows developers to build rapidly and have fun whilst doing so!

It has integrations with Vue Storefront and Next.js Commerce, meaning you can get up and running with a basic full stack headless commerce store in literally minutes. It is used in production on projects of all sizes, from solo founder-built shops to rapidly-growing startups to Fortune 500 enterprises.

So if you are looking to start an e-commerce project and you think that a headless, open-source framework would be a good fit for your requirements, get started with Vendure!