That Free Puppy Sure Is Cute

Why writing software has never been the expensive part.

There are a couple aphorisms about software development that seem apt right now.

The kernel of truth behind all of these is the fact that operating and maintaining software is not free of costs. This seems to be lost on a lot of people writing about or advocating for the use of (increasingly capable) AI code generating tools.

Similarly, I constantly hear comments around how much software is going to be produced using these tools by non-programmers. I hear fear around the future job prospects for software developers. And indeed, layoffs of technical people in software companies are occurring and are often attributed to the efficiencies supposedly being gained by using AI tools.

Free Was Always An Option

What all of this ignores, however, is that "free" software was always an option. For any broad category of software-as-a-service with a market leader, there has existed, since well before Claude Code, an open source alternative you could download and run without having to pay anyone a license fee or subscription. Salesforce is the market leader in CRM, yet open source CRMs have existed for years. The catch is, you have to run them yourself (free: as in puppy).

I started my career in the days when most software was sold with a 'perpetual license' and installed by the customer on their own hardware. SaaS was still a new and radical idea because the Web wasn't quite ready to be the application platform that it is today. Companies owned vastly more hardware than they do today and often ran what was effectively a miniature data centre in the back of their offices with racks and racks of servers to handle the databases and application servers for the software they'd purchased. Part of my first job often involved flying to another city with a CD-ROM containing the software, going into the customer's server room and showing their IT staff how to set up and distribute the software to the company users' desktops.

The Server Room is Closed

SaaS, delivered over the web, more or less killed this off entirely. And not because the other ways of delivering software weren't available, but because companies didn't want it anymore. It was vastly preferable for almost everyone to 'rent' software from a vendor who provided all of the hardware and labour needed for monitoring, troubleshooting, scaling, and patching needed to keep mission critical applications running. 'Perpetual License' on-premise software usually had a provision for a maintenance subscription so you'd at least get sent updates with bug fixes and new features, but if the hardware it was running on failed in the middle of your busiest, most important work, you were on your own.

Today's 'Free' software is basically that same model. As long as it's maintained by somebody, you'll get bug fixes and new features but everything else needed to keep it up and running all become your responsibility. (free: as in puppy.)

There's nothing inherently better about browser-based software delivered via subscription service. There are still some things that native apps are better at, but the model won out because of how much easier it was to rent rather than own.

What's that Sucking Sound?

All of this is equally true for that impressive, vibe coded app someone in the support department custom built that solved a real problem that wasn't covered by any of your existing tools. In fact, it's so great everyone started using it and now it's a critical part of the whole support team's workflow. Hooray! Except now the person who created it is spending most of their time dealing with feature requests and bug reports instead of what their job was supposed to be and their manager is trying to find someone in product or engineering who can 'take it over' so they can get back to their day job. As soon as other people started depending on it, the moment that puppy was adopted.

Meanwhile, engineering is recovering from the recent reductions in force and trying to make sure there's adequate ownership coverage for the stuff they already maintain while VPs from Support and Sales are insisting that they need help from Engineering and IT with deploying even more 'internal tools' the team built using Codex. Engineering will get stuck with these ownership costs because they're the only ones who really know how.

You Need a Plan

It's clear from reading and hearing perspectives of people who have never been responsible for operating software that they dramatically underestimate the cost of operating software. They over-index on the costs of creating that software in the first place, and treat the operation and maintenance as a rounding error that can safely be ignored. We know this isn't true. Datadog is a company worth billions that 'competes' with free products like Prometheus, Grafana, and Logstash because people would rather pay them rather a lot of money than deal with the kinds of requirements a tool like that has and the burdens that trouble-free operation of something mission-critical puts on the team responsible for it.

Nevertheless, the push from execs to use Claude to "solve your own problems" is going to persist for a while, and the people who have successfully solved their own problem are going to work to push the pains that come along with it onto engineering teams who have the skills necessary to do all of the non-code-writing aspects of software development. Maybe AI reduces some maintenance burden too, it's possible. But even if that’s true, somebody still owns the outcome.

Engineering and Product teams should be factoring this into their capacity planning. You might not know what precisely is going to get shoved onto your plate, but free puppies are adorable and hard to resist. There's a fair chance you'll adopt a few before the CEO realizes you've taken on too large a burden and puts a stop to it.

Image: "Server room at CERN" by torkildr is licensed under CC BY-SA 2.0 .