Outage outrage

If you’ve been following us for a while, you know that we’re not the ones to sing Shopify’s praises when they’re undeserved. In fact, we have been quite critical of Shopify’s strategy in the past—back when that strategy implied the existence of a single, obviously correct way of doing things, and that anyone who ran their business differently didn’t know any better.

Still, after experiencing Shopify’s 45-minute outage this Monday and reading the resulting barrage of snarky LinkedIn posts, we are very conflicted.

There are two sides to this matter that we’d like to explore today:

• Much of the commentary comes from people who have never operated a complex software system (or have conveniently forgotten about it).
• The high expectations of Shopify stem from Shopify’s own marketing, but also from their semi-god scale and public perception.

Let’s do this.

First of all, for anyone who says Shopify’s engineering team is dumb because how could they get a database migration wrong in 2023 and they should be using more AI in their development process and why were they not already doing a code freeze in the first place and—for all of them, we have four words:

Give  them  a  break. 

Here’s the thing: software is complex. Complex, as in “It is literally impossible to enumerate the million small things that need to go perfectly right in exactly the right sequence for this rollercoaster to keep rolling.” As a result, software is also fallible: every piece of software you use is in a constant state of brokenness. Yes, even Shopify.

The only reason the world’s not on fire yet is that, as technology becomes increasingly important, technologists become increasingly good at containing the surface area of their mistakes. This is done through automated tooling, development workflows, business strategy, and a sane amount of good old common sense.

Some of these practices can seem very counterintuitive to an outsider. For example, code freezes are rarely a good thing: the consensus in modern software development is that the more often you ship software, the less likely you are to break something. That’s because shipping more often requires you to put safeguards in place to eliminate the cost of making a mistake, which makes your software more resilient.

Sometimes, a code freeze is a necessary evil, as the impact of making a mistake is still too high, no matter how much you try to contain it. But for a technology company, nine times out of ten, the benefits of continuing to ship software far outweigh the dangers of making a mistake.

In other words, Shopify enacting a code freeze because they’ve screwed up once was an overkill, reactive measure: this was an isolated, one-time incident that was mitigated swiftly, and Shopify’s engineers are putting safeguards in place to ensure it won’t happen again. The only consequence of the code freeze is that merchants will not be able to benefit from any improvements or new features that Shopify was planning to release leading up to BFCM.

Additionally, everyone’s watching Shopify, so we can safely assume that at least some other providers will follow suit in fear of screwing up and being put on public trial. It’s not outlandish to hypothesize that those potential new features and optimizations might have led to millions in incremental revenue for Shopify’s merchant base. That, and not having 45 minutes of downtime, is the real screw-up.

The other interesting question is how we went from having technology-driven e-commerce brands that build their own checkouts and AI models, to having brand founders suggesting that, if only Shopify lifted their ban on group meetings, then these things wouldn’t happen (real LinkedIn post).

We’d love to say that this is all Shopify’s fault since they—along with many service providers—spent a good part of the last 15 years telling e-commerce operators that they don’t need to worry about technology at all, and that their e-commerce infrastructure would be magically taken care of if they only took the Shopify leap of faith. But this delusional overcorrection is something we have written about in the past, and it wouldn’t add any value to rehash it now.

Instead, we need to realize that this kind of scrutiny is what happens when you become part of the economy’s entrepreneurial fabric. When so many people rely on you to run their business, you should expect a lot of them not to understand much—if anything—about how your product works. For any Shopify detractor in the last two days, there are thousands of supporters who would happily fall on a sword if only it had the Shopify logo on the pommel.

There is one caveat, though, and it has to do with Shopify’s upmarket plans.

Right now, Shopify merchants have pretty limited visibility into the platform’s internals. If you need proof, just put on your Big Company CIO goggles, look at Shopify’s status page, look at commercetools’ status page and Commerce Layer’s status page, and see who comes out on top.

If Shopify wants to move into the enterprise segment, it needs to do better and provide context and data that go beyond Shop Pay’s conversion rates—as amazing as they might be. Otherwise, they will have a hard time competing with platforms that rely on and play into their customers’ technical maturity.

And this isn’t limited to their enterprise ambitions: as it becomes more technical, there’s an opportunity for Shopify to lean into a more balanced narrative and really educate operators on the role of technology—a crash course in e-commerce tech literacy, if you will. This kind of move might dissipate some of the magic in Shopify’s brand promise, but it would also help reset their average customer’s expectations.

Our hope is that, armed with that new understanding, we won’t spend the days following Shopify’s next outage looking for lambs to sacrifice, but rather for lessons to learn.