Exploring Commoditisation

Hello futurists,

This week, we’re exploring the force of commoditisation in web products, giving you the tools to focus on your core competencies and spot new opportunities for company building.

What is commoditisation?

Commoditisation is the market force that pushes you from writing your own code to using other people’s. In short, it is the force of technology. Commoditisation is captured in Simon Wardley’s Wardley Maps, a tool for anticipating and navigating technological changes. In these maps, Wardley lays out two axes on which to plot components of your product: stage of evolution (how developed the component is) and value chain (how close the component is to your user).

For example, a database is far from your user and part of a well-developed market, while an authentication service like Auth0 is somewhat closer to your user and a little less developed. See if you can place these components on the map of an online photo service above.

Wardley spells out specific stages of evolution that components of a product may fall into:

• Genesis: The truly exploratory.
• Custom built: What is bespoke, rapidly changing, a differentiator.
• Product: Easy to purchase, from a competitive market.
• Commodity: You don’t even think about it. The completely undifferentiated.

Mapping out your product like this is a great way to produce an overview of what you are building. For me, however, the crucial thing about stages of evolution is that they evolve. Custom built code eventually gets productised, products eventually become commodities. This evolution is the force of commoditisation.

Commoditisation as abstraction

There are several other lenses we could take on commoditisation. The first is the lens of abstraction.

Commoditising components involves a form of abstraction. Moving from an on-premises server to AWS is like writing Python instead of C. Sure, you loose something in the abstraction, but your product will be much easier to deal with.

‘Do not repeat yourself‘ applies across companies, not just within them, and embracing commoditisation is an excellent way to leverage the more powerful tools that abstraction provides.

Commoditisation as focus

One of the strongest advantages of commoditisation is focus. Especially in the startup ecosystem, lack of focus is a business killer. Abstracting away components through commoditisation can not only save money but also free up employees’ time and headspace to work on what matters.

Commoditisation as innovation

Almost by definition, riding the force of commoditisation is a way to capture innovation. This can be accomplished in two ways.

First, additional focus in a business allows employees to leverage their core competencies to build more innovative products. Less time configuring servers, more time serving users.

The second way of achieving innovation through commoditisation is by utilising feature sets of external products. For example, one reason to use a low config hosting provider like Vercel is that it saves engineers time, but moving hosting to a more productised solution also means that you get other features such as a CDN, deployment rollbacks and per-commit builds for free. Let other companies focus on their domain, and they’ll help you focus on yours.

Commoditisation as a threat

The flip side of ‘commoditisation as innovation’ is ‘commoditisation as a threat’. Ride the wave and you will innovate; miss it and you will be left behind. As an extreme example, if you’re not using source control, your company is essentially dead. If a component has reached commodity level, you better not be building it yourself or, worse, have missed its benefits entirely.

Commoditisation of web products

How do we start leveraging these ideas? One approach is to use commoditisation as a mental model for thinking about how to build (or purchase) components for your product.

For pre-existing products, ask what you are wasting time building yourself that should be purchased as a product. What abstractions are you missing out on? How can you spend money to save engineering hours?

For new products, commoditisation is a powerful tool for focusing on innovation and rapidly delivering user value. For example, Notion‘s core value proposition is being the best all-in-one document editor, not better internal DevOps, so they were still using Heroku to host their app rather than expend effort on a more ops-heavy solution like AWS, despite achieving the funds and scale that would traditionally warrant hiring an infrastructure team.

It can be useful to break down components by area (for an interesting comparison to this 2020 list, see this post from 2015). We might speculatively and historically plot out the following commoditisation trends.

Hosting/Runtime

On-premises server → Cloud server → Low config server (e.g. Heroku) → Serverless → Runtime as a commodity?

Data

Network/hierarchical databases → Relational Database → Backend as a Service (Firebase, Hasura, Prisma, FaunaDB) → Data as a storage as a commodity?

UI Frameworks

Vanilla JavaScript → jQuery → React → ?

Builds

Script tags → Gulp → Webpack → Webpack abstractions (e.g. Next.js, Gatsby, Create React App) → Zero config building?

Authentication

Custom built → Libraries and plugins (e.g. passport.js) → Authentication as a Service (e.g. Auth0, Firebase) → Authentication as a commodity?

Payments

Mess of banking APIs + regulation → Stripe

Image Hosting

S3 → Cloudinary

Content Sites

Hard coded HTML, CSS + JS → Website builders (Webflow, Hubspot, SquareSpace)

Internal Tools

Build your own → No Code (e.g. Retool)

Company building and commoditisation

The above has mostly been from the angle of utilising components for pre-existing products. But a perspective I found far more interesting is to look at commoditisation as an idea stream for building new opportunities. What if you want to make the next component yourself?

Writing out the category trends above, it becomes easy to spot what I want to come next. I’m a big fan of serverless but the ecosystem is still a bit splintered. How does it become more unified? React has been an incredibly powerful tool, but what comes after it? Given that the end goal of all web app builds is the same (as fast and as small as possible), why do we still need to configure tools like Webpack over and over again?

I’d love to see companies in the following areas:

• Performance Monitoring: Currently, high-performance web apps are building their own performance monitoring tools (see Superhuman’s process here). How do we make this process into a product?
• Design Systems and Component Libraries: Why is every company building component libraries in-house? How do we abstract away what is common between them?
• Data Tracking: Why is adding data tracking to a web product so manual? How do we shift this process from custom built to something more productised?

What do you want to see built? What are you building? What trends have I missed? Hit ‘reply’ and let me know.

Quick Links

• My local bike shop wins the award for best designed website
• Raycast: if Alfred and Superhuman had a baby
• GitHub releases their new CLI

Ship List

Things I’ve been shipping this week. - Now collecting signups for my touch typing tool for developers, https://typeperf.com/

Most new readers come from a friend’s recommendation. If you enjoy it, you can share the newsletter on social media or forward this email to someone you think might like it.

I love hearing from strangers on the internet so if you have any thoughts or feedback, or just want to say ‘hello’, feel free to hit ‘reply’ or DM me on Twitter.

Spam filters sometimes get a little trigger-happy so if you find this email in Gmail’s Promotions tab or your spam folder, please drag it into your inbox and help other readers find the content.

See you next week,

James