Why is selling software so weird?
If you squint enough, building software looks a lot like building a house.
In both cases, you start with a problem and Frankenstein together various components using rules of thumb until you have something that looks like a solution.
Because the crafts look so similar, you’d be forgiven if you thought the business models behind building software and houses were similar. They couldn’t be more different.
When you’re building a house, you have a pretty good idea of how many people that house will impact. The market has already demonstrated that they’ll pay for a roof and a walk-in shower and a state of the art heated toilet seat. If you erect a sturdy 4 bedroom, 2 ½ bathroom house with these amenities in a desirable neighborhood, you can rest easy knowing that you’ll be able to sell it.
This is not how software works.
The main problem here is that houses and software have wildly different marginal costs. If I build a house and my neighbor really likes it and wants to live in a house that’s exactly the same, it will cost them almost as much to build as it cost me. Sure, they might be able to save a few thousand dollars on architectural fees, but they’ll still need wood, wires, and boatloads of time from skilled plumbers, electricians, and carpenters to assemble those raw materials into something resembling a house. Marginal cost is just the cost to produce one more unit of something - in this case, one more house.
Contrast this with software, which lives in the realm of often-near-zero marginal costs. I can’t make a living building Zoom for someone because Zoom already did that. The marginal cost to Zoom of onboarding a new customer is almost zero, whereas the fixed cost to me of recreating Zoom is astronomical.
Building houses is a great business because those high marginal costs for each new house are paid to you. The work you do correlates pretty linearly with the value you provide, providing you with a steady stream of income and feedback that the thing that you’re doing is actually useful. The trade-off is that it’s hard to gain much leverage in your work, with leverage meaning something like “how much impact can I have for every hour I work”. Whether you work on a small project with a small impact with a small team or a big project with a big impact with a big team, the amount of impact per person might vary by 1x or 1.5x or even 10x, but the physical nature of the work makes it hard to stretch the impact much beyond that.
Software is a great business because, if you can build something that’s useful and provides $10/month of value to someone, it’ll probably cost you a lot less than $10/month to provide that value to a second person. Multiply that by 1,000 and you’re getting paid to do a full time job, even if you only work 5 hours per week. Multiply that by 10,000 and you can retire in a few years. It’s an extremely high leverage business.
This makes software a weird anomaly. Paging back through history, there have been very few opportunities for near-zero marginal cost goods. Probably the closest parallel to present day software in history is publishing companies, where additional prints are cheap compared to the cost of creating the content in the first place.
Unfortunately, there are three significant downsides to software’s low marginal cost structure:
First is that software takes a lot of time to write up-front. By the time you’ve signed up your first customer at $10/month, there’s a good chance you’ve spent 100s or 1000s of hours writing that software. Low volume software is not a good business to be in.
The second downside of the “high-leverage” software model is that unless you aggressively seek out feedback, you’ll probably realize that your software sucks only after you’ve built it and can’t find a customer. The digital nature of software makes it extremely easy to ignore pesky distractions like customers right up until the moment you need their money to buy that expensive Icelandic yogurt you love.
The third downside is that, unless you can differentiate your product from what already exists, it’s going to be hard to find a foothold in the market. Given how many software products already exist, that’s a high hurdle to clear.
The distribution of “value created by people building new houses” is probably some sort of a normal distribution that’s anchored in the cold-hard reality of the physical world:
There’s almost no one in this distribution creating zero value, but there’s also almost no one creating hugely lopsided value.
Compare this with “value created by people building new software”:
Here, you have the vast majority of people building new software creating no value, some people creating a modest amount of value, and a few people creating tons of value. This is what’s known as a power law distribution: a very small number of outliers account for the vast majority of the impact.
If you’re building software - particularly new software that hasn’t already found a market -this underscores the importance of being good at what you do: if you’re just average (or more precisely, just median), you’re creating zero value.
This is also why this blog focuses on how to build successful software: for each few percentile you move to the right on that curve of outcomes, the value you’re creating increases exponentially. To achieve this, you need to not only build high quality software but also understand adjacent ideas like identifying promising distribution channels, soliciting and incorporating customer feedback, and building defensible moats around your business.
These are the things that can transform a “software engineer” into “someone who can solve problems using software”. The latter is a heck of a lot more fun.