But I think that statement misses an important part of the cost of software: the weight.

Everything you build or adopt has to be integrated, maintained, updated, secured, monitored, and debugged when it breaks. You also have to manage the infrastructure it runs on, keep up with dependencies, handle edge cases, and make sure the thing still works when the business starts relying on it.

That ongoing operational burden is what I mean by weight. It costs real time, focus, and money. And if anything, the pace of change has made software heavier, not lighter.

That's why the “we could just build it ourselves” argument is dangerous. Because while yes, in many cases, you probably could. But what what the statement misses is what those teams would have to stop doing to build it, and what they would have to keep doing forever after.

I run a SaaS company, so yes, I have skin in this argument. But I don't think this is really about whether someone could build what we have built, or what any other SaaS company has built. The initial build was only ever one part of the cost.

You see the a lot of the real cost of software is in the parts that are boring until they are expensive: scaling, infrastructure, security, migrations, monitoring, backups, incident response. Like a lot of things in life the devil is in the details.

None of those things feel like the “product” when you are building the first version. But once the software matters to the business, they become the real work. Databases are a good example. They sit underneath everything, quietly carrying more and more of the business until performance, cost, reliability, and risk are no longer future concerns. They are operational problems someone has to do something about..now.

So maybe writing software is “free” now.
But carrying it isn't. Ask any DevOps engineer or DBA you know.