Any startup that provides value through a software service needs to work with devops. Devops is the set of practices that take a software system that runs in one computer (usually, that of who develops it) and makes it run in multiple networked computers. In other words, devops is what allows you to turn software into a service.

Recently I read Marc Andreseen’s Onion Theory of Startups, where he explains how the key to get a startup financed is to remove layers of risk from your plan, in order to minimize the risk of investing in it. This derisking is done in layers.

I think that devops represents a significant layer of risk on any software service startup. Devops is an enabler, and its limitations can have negative effects on a startup, ranging from significant to fatal.

Let’s examine the devops risk layer.

A devops structure is what allows a software startup to create a service that has the following properties:

• Scalability: can quickly be scaled up to meet the demands of more users. If what defines a startup is its accelerated rate of growth, then the service it offers must be able to grow at very significant rates. In the face of this growth, if the service remains highly available (ie: has as little downtime as possible) and performant (ie: responds to user requests quickly), then the service is scalable.
• Speed of change: allows to update the service very quickly. This is essential, since a startup figures out what to build while it builds it.
• Secure and compliant: any service must secure its users’ data, from both external and internal bad actors. And, for B2B startups, you not only have to secure things, but also pass audits and also give an illusion of security to your customers. (The snarkiness springs from the emphasis of big corporations to trust rubber stamps more than fundamentals.)

The main three devops risks, conversely are:

• Making a service that cannot scale up fast enough.
• Making a service where the company cannot iterate fast.
• Making a service that is insecure and noncompliant.

In B2C software, the first two devops risks are the most fatal, particularly the second. The speed of iteration a startup is a main factor in its capacity to create value, since a startup is discovering how to create value by running a live experiment (the product itself). Once early successes find critical mass, and the startup reaches what can be described as product market fit then the first risk is the most acute: can you deal with the flood? Pinboard managed this after barely surviving it.

In B2B software, especially when selling to bigger companies, the volume of traffic won’t be large even after product market fit. The speed of development is also much more forgiving (given the sclerotic nature of large companies), though maintaining development speed can be a great advantage to startups. The biggest devops risk for B2B is security and compliance. If your service is not secure, and more importantly, if its not certifiably secure, then that will block the startup from closing deals with its customers, no matter how otherwise great its offering.

I contend that minimizing risk along these three dimensions of devops is the main devops task of an engineering team in a startup.

There’s a few ways to go about it:

• Build a dedicated devops/SRE team (the Google way).
• Enable your devs to own devops as part of general software engineering (the Amazon way).
• Hire devops as a service, either as consultants or through a product-based offering.

Something that is not that important, at least not at the beginning, is infrastructure cost. Servers are cheap, people are expensive. Though it might offend some sensibilities (including mine), if you spend a few hundred dollars in infrastructure per month (rather than a few tens) and you barely have traffic, that’s not going to make or break your startup. Once your infra expenses start going into the thousands, then you really need to look into cost, but not until then. Anyone that is able to look into devops cost will also cost themselves thousands per month. I’m not saying you should overspend in infra, all I’m saying is that it’s not as high a priority as the things above.

The devops risks are a wonderful justification for my pursuit of simplicity, particularly in devops. The way I see it, simplicity can massively help derisk the devops aspect of a software service:

• A simple system is easier to scale, because the dependencies are few and well understood, therefore is more easily parallelizable.
• A simple system is much easier to change than a complex one, because the effort of implementing changes is roughly a quadratic function of its complexity (I just made up that rule but I think it’s more accurate than saying that the relationship is linear or nonexistent).
• A simple system is much easier to secure: easier to understand all its surfaces, fewer dependencies that could generate vulnerabilities, and easier to test it as a whole.

Rather than railing against the complexity of the devops landscape as of the time of writing (2024), I see there a big market opportunity for startups that want to bet in simplicity. If you build a simple and effective devops layer, your company will have a solid competitive advantage (because of scalability, speed of iteration and increased security) compared to competitors that go with a more conventional (read: complex) approach to devops, based on using new shiny tools and following through on semi-curated lists of best practices.

A frontal approach towards devops simplicity is no small bet. It has to be done carefully and well. It has to be based in fundamentals. I’m particularly wary of security and compliance; in that regard, unless you’re an expert, you’ll probably need external advice and certification.

If you peel that devops risk layer successfully in your software service startup, do let me know, I’d love to find out how you did it.

Best of luck peeling that onion!