Rent vs Buy vs Build

This content originally appeared on Robin Osborne and was authored by Robin Osborne

AKA “Is your Company a Software House or is it a Retailer?”

These days you can easily set up an online shop in a matter of minutes/hours, buying no hardware, setting up no software; just signing up to something like Shopify (or WooCommerce if you’re using WordPress) for a few coins a month and you can sell goods and services online.

You’re spoiled for choice if you have more money to invest, thanks to a proliferation in professional solutions for being an online retailer.

The complexity hidden behind these few setup clicks is quite staggering for those of us who were involved in building e-commerce in the earlyish years.

Back in the early 2000s, there weren’t many options for powering an e-commerce website. Without regular reviews of the ecosystem, some of us might have fallen into the trap of spending a lot of time and effort “writing software” instead of solving business problems or helping meet business goals; the “Software House” vs “Online Retailer” dichotomy.

For example…

Content

In the really days of E-Commerce your Content Management System (CMS) choices were limited, to the point that many of us cut our teeth in the industry by thinking “how hard can it be to build a CMS?” before wasting months of our lives discovering the edges of what a CMS needs to actually do and vowing to just pay for someone else to build it for us next time.

And that’s just managing content that might appear on a web page, in various languages, updated via a separate user interface that someone less technical needs to interact with. Which is a product within itself. Should we really be building this if we’re not working at a Software House?

Product

Let’s get further into the hidden complexity I hinted at; an e-commerce website needs some fairly obvious features:

• Display many products
• Display a single product

To the techie brain this might seem quite simple (and let’s assume it is for now):

• Display many products: a list of records from a database, displayed on the screen (easy!)
• Display a product: one specific record from a database, displayed on the screen (pah! a breeze!)

Might as well just build this ourselves, right?

But how does that data get into the database in the first place? Who enters the data, and how? What is the operational process to say “this product is ready to be displayed and purchased”?

Now we’re getting away from “tech” and back to “product management”.

A workflow or process that involves several people over several locations – sometimes several teams or several companies – to order goods, receive goods, check the quality of those goods, take photos, associate photos with products, enter prices, enter product details – translated for different markets, obviously – and SO. MUCH. MORE. Which is a product within itself. Trying to constantly overcome these obstacles by writing software might not be the correct solution to achieve the goals.

Payment

Now a user wants to buy one of these nicely displayed products; we’re talking about user account management, securely handling personally identifiable information – which can be painful; annual PCI compliance reviews, anyone? – taking payment details from a customer via a website, talking to a bank to take their money, updating the internal accounting systems, etc. Which is a product within itself. Should we be putting ourselves through this? Is there an easier solution?

Fulfilment

Now that order has to be fulfilled; it needs to be sent to the fulfilment centre (e.g., warehouse), the products need to be found (some clever mapping system to optimise a warehouse worker’s route, of course), packaged, and shipped (via the relevant shipping provider), tracked, and all this communicated back to the user and the accounting system as products leave. Which is… yeah. Surely an online retailer has better uses for those limited funds?

Enter: “Backoffice”

It was around the early 2000s that I started working at Asos (then known as “As Seen On Screen”, where you could buy products that you would have seen on TV and in films, likely due to these products being placed in that show by a company called Entertainment Marketing, from which Asos was spawned).

Low on budget, high on youthful enthusiasm, we essentially built all of the above, and much more.

A full, end to end, Product Information Management (PIM) workflow solution; a CMS with translation workflow; an Order Management System (OMS) – all as a horrible blue and yellow .net WebForms website (without the benefit of designers to help make this side of the website look good, it fell to techies to squeeze <table>s everywhere and choose colours like salmonpink and goldenrod because they sounded funny), which we called “BackOffice”.

We built dozens of Windows applications which had to run on a specific server which we accessed via RDP to view a screen full of running application GUIs since we hadn’t learned how to make windows services yet, all to process orders, process payments, integrate with the warehouse (Warehouse Management System, WMS), integrate with the barcode printers, process the product ordering workflows, etc.

Half of the IT department was dedicated to managing these internal systems which evolved massively over the following two decades; several being replaced by emerging systems that focussed on solving these problems better than would have been managed internally.

Each of which is a product within itself

I’m reminded of this work after attending a recent tech event for a well known Product Information Management solution; I had the opportunity to meet with the founder and CEO, and discovered that the entire product came about because he worked for a consultancy that, like we did at Asos, built a custom solution for a client in the early days of e-commerce, but they kept the rights to that intellectual property. They realised the value of this solution, white-labelled it, and continued to evolve it as they brought more and more clients on board. This is now a very successful and complex product.

It made me think about how, had we the entrepreneurial foresight back then, we might have been able to take each of those systems we created for one “client” and spun them off into their own white-labelled products, developing separately; a decent enough CMS, a decent enough PIM, and decent enough (and PCI compliant) payment processing and accounting solution, a decent enough Warehouse Management System. We had certainly invested enough time and effort in each of them.

How does your company make money?

All of which brings me to another question I like to subtly ask when I’m getting involved with clients who are keen to build their own in-house solutions: “are you a software house, or a retailer?”

Building a CMS is no easy task. Integrating with a complex “MACH” one is no easy task either, to be honest, but using something well established like WordPress can be quite manageable.

The same is true for a PIM, OMS, Payment Processor, WMS, etc. Maintaining each of these is just as much work as building them. Evolving each of these to adapt as the surrounding ecosystem shifts equally takes a lot of effort and time.

If, like the company whose event I attended, you can make money by selling the software you’re intent on writing yourself – congratulations, you’re a Software House! Stop selling other products (or at least, split the company)!

However, if, like so many websites out there, you make money by differentiating on the products you sell and not how you sell them, then maybe consider if spending all this money on solving an already solved problem yourselves is where you want to invest long term.

Are you the company that Builds a solution, or a company that Rents or Buys from that other company instead? Make sure you take a step back before diving in and “writing code” instead of “solving the problem”

This content originally appeared on Robin Osborne and was authored by Robin Osborne