The Bull Thesis for Consulting

Software is eating the world, sure. But I’m starting to feel like it might be eating the current model of its own development and consumption as well.

In the old days, a business added a bunch of software developers to its payroll, and those developers figured out a way to leverage computers to aid the business in its mission. Generally this worked out, since computers are so useful that it’s not that hard to stumble into a useful application, especially for an existing business.

Nowadays, utilizing computers is table stakes for a business, whether they like it or not. There are basically two ways to interact with software:

1. Make it
2. Consume it

Over the last few decades, most businesses doing something novel have had to engage with (1) in a serious way. However, we are trending towards a reality in which nearly every first-order capability is offered as a SaaS. When I say “first-order capability” I mean the basic building blocks of a modern internet business: user management, authn/z, payments, support tooling, customer comms, marketing tooling, analytics, etc.

The implication of this trend is that there will be increasingly more potential businesses to be started that do something novel without having to write large amounts of custom software. Instead, they will simply have to wire together existing managed components, and season it with some proprietary spice blend.

Unfortunately, most highly-skilled, career-focused developers don’t want their job to just be owning a bunch of integrations, so they become less interested in working for the median internet business.

On the flipside, the leverage accruing to those companies doubling down on making software (often in order to provide first-order services as SaaS) will continue to increase. Assuming current valuation for SaaS businesses are rational and durable, there will be no end to the pile of unicorns sucking up talent with interesting work and long-right-tail comp packages. Since the software makers and consumers compete in the same labor market, this also has the effect of dragging the entire comp distribution upwards somewhat.

Now let’s briefly touch on the differences between onsite deployments and SaaS as it relates to the business. With an onsite deployment, the entropy of the system is on your books. In other words, stuff breaks, libraries need updating, and its yours to fix. With a SaaS product, the entropy is owned and managed by the provider.

In the pre-SaaS days, you, let’s say an ecommerce business, would pay a dev shop to build a customized Magento franken-app and deploy it on a handful of VMs. Either the investment failed and you gave up on this software crap, or it worked well enough that you eventually needed to modify it, or fix it, or whatever. At this point you either hired a dev team, or you called the dev shop again. Either way, you owned code and the deployment, and therefore the entropy.

With SaaS, you can wire up a bunch of products that ultimately do the same thing as your old Magento franken-app, but don’t expose you to the entropy. As long as the SaaS providers continue to exist (and you continue to pay them), your product’s components will continue to be supported. The piece that you actually own is just the glue between all the services, which is a much smaller component than if you’d had all the functionality built in-house. However, it’s not nothing. It required technical knowledge to build. Only so much complexity can be shifted to a SaaS provider; every business has its quirks, and every SaaS ships a surprise breaking change sometimes.

To summarize, we’ve identified three trends thus far:

• The median internet business doesn’t need much in-house software to function, because they can just wire a bunch of SaaS pieces together.
• The median internet business has trouble attracting and affording developers.
• Wiring all of these SaaS components together requires the technical skill of a developer, but once performed it doesn’t require much maintenance due to the nature of managed services.

So, does it make much sense for you, internet business owner, to add a whole team of developers to your payroll? Yes, if you’re attempting something that can’t be done w/ SaaS primitives. Otherwise, it’s probably cheaper and much less mentally taxing to keep a good dev shop on retainer to handle all your SaaS integrations.

P.S. – I have no data that suggests that businesses are hiring fewer developers or buying more development consulting services. If you do, I’d love to see it.

P.P.S. – Looks like the fine people at Scope are having similar thoughts; they’re building a platform that addresses this new paradigm.