Software Has Been Almost Free Since 1992.
So What Are You Paying For?

Why did building software become free… in 1992? Who was writing code on paper? What's hard in building software and will remain hard? Is a JS bootcamp a good idea in 2026? Can non-programmers build good systems? And finally, what implications does all that have for our customers and the business models? Those are all the questions I try to answer in my take on what the AI revolution will change in software development in the near future. And what will not. It's based on 20 years of my professional experience and a little bit of digging into the deeper history.

When I was doing my research for this article I came across a few interesting articles. One of them contained this statement: "Software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free". The statement may not seem absurd today but knowing that it was published (by Jack Reeves) in "C++ Journal" in 1992 makes it a different story. One that many people who have worked on IT projects over the last few decades and have seen the bills may easily argue with.

But it gets even more interesting, especially from today's AI-boom perspective, when you get into the details of the author's argument. What he's saying is basically that while software is cheap to build, it is extremely expensive to design. And according to Reeves, who draws a few parallels with the hardware industry, the source code is the only actual design that meets the formal criteria in the engineering sense. The software that's cheap or even free due to technological advancements and ever-reducing hardware costs (this didn't age well…) is what compilers and linkers produce. Reeves also makes an important point that building and designing require different skillsets.

From today's perspective we don't often think about the fact that at some not-so-distant point in software's history, people were writing machine code. When my father started his professional career, he wrote software on punch cards. Some of my colleagues wrote code on a piece of paper for a university exam as a proof of understanding algorithms. Those skills required some big brains, and they are largely unnecessary today. Did this shift make software development free?

Over the last few decades every major technology advancement in software engineering has been aimed at making software development more abstract and more accessible and easier to perform. One can think of it as more and more layers over machine code.

When structured and later object-oriented programming languages evolved it was a massive boost to productivity. It was also easier to understand than assembler. It did require a bit different skillset. Does shifting from assembler coding to system design (in Reeves' sense) seem familiar already?

And while the code crafting part became increasingly accessible to a wider audience via better IDEs, modern programming languages, auto completions, Stack Overflow (R.I.P.) and many others, there seem to be a few things that don't change. This was stated in another interesting paper, this time from 1986 (!), by Frederick Brooks. The whole paragraph is worth quoting.

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

Exactly 40 years later it is still valid. I'd like to build on that. Implementing a successful IT system has always consisted of the following six key elements/stages:

• Understanding the need
• Designing a solution
• Building the software
• Hosting the software
• Implementing the software in the organization
• Supporting/developing the software

The total cost of successful software system implementation is always the sum of the six. Over time and with each technological or organizational advancement, some of those elements changed. The arrival of high-level languages and modern IDEs made the building part cheaper and faster. Agile methodologies (supposedly) made the understand and design phases more efficient. Popularization of Cloud allowed organizations to reduce the costs of hosting, made it more accessible and reduced up-front investment. Some professions and skills disappeared along the way (how many devs know assembly nowadays?), new ones such as Scrum Masters or DevOps popped up. Lower workload in one area often produced more workload in another.

There are not many reasons to think that this revolution should be any different. We got another, very capable, layer on top of modern programming languages that makes producing code more accessible, faster and cheaper. And while I believe that the era of masses of people doing JavaScript bootcamps to start working as Junior Devs in IT is over, I think that the other elements have remained the same or even gained in importance. Someone still needs to understand what needs to be built and how it should work. The system needs to live somewhere. And someone should pick up the phone at 2am if something breaks, taking the responsibility. Oh, and it would be great if this someone actually knows what they are doing.

So, what does this mean for the buyers of software? Same software cheaper and faster seems to be the obvious answer, but somehow it doesn't work this way. I think that there are far more interesting and disruptive scenarios.

First, when the production of code becomes faster and cheaper, you can prototype much faster. And by prototyping I don't only mean the phase when you're doing pre-sales for the customer and show up for a second meeting with a working PoC rather than a PowerPoint and a pack of mockups. I mean every single stage of the Software Development Lifecycle.

For years we had to put a lot of effort into de-risking projects during the analysis/design phase, because building was expensive and changing the built product was even more. A lot of effort was taken up-front to make sure everyone is on the same page. Also, a lot of complexity came from future-proofing a solution. Very often against scenarios that never happened. When you only get one shot, everyone is scared they'll get it wrong. And they'll put a lot of effort into making sure they won't. An effort someone needs to pay for.

Moreover, when you need to wait long for the build, the risk that the environment will change and make it obsolete is significant. It no longer works this way. Building and re-building is fast and cheap now. Need to rewrite the solution to use different tech stack? Easy. Change the data structures? No problem, hold my Claude. It's better to start building something fast, validate with users and implement feedback than try to plan for everything. Of course, this works as long as you have the right tools to keep track of what happens and why and the right background. Remember that this works both ways and building fast lets you build a bad system fast too.

What practical implications does that have for the customer? Apart from working software within weeks, not months and at a fraction of up-front cost – it de-risks projects. In a typical scenario when a non-technical customer approaches a vendor, both parties have a big gap in understanding of each other. This gap is smaller if the vendor knows the industry, has done similar projects or specializes in a given area, but it's usually there anyway. There's no better way to close this gap than to start talking about something that works and improving it instead of talking about whiteboards, design docs and contracts.

This opens up new and interesting business models. The initial risk gets much smaller so a capable software vendor can take some (or all) of it on themselves. Organizations that didn't have the financial or organizational capacity to build dedicated software now have it within their reach. Many projects that went to the freezer because the risk couldn't be justified can be brought back to life at a fraction of effort. It's also possible to construct different financial models as the cost of producing software is no longer derived from a simple equation "Hours x Developers".

Another direct benefit to the customer is that with a proper set of tools and a well-engineered Software Development Lifecycle pipeline with proper human gates the software can be built by people who are not strictly programmers in the traditional sense. In the traditional model, people who talked to the customer were rarely the same people who later built the solution. Depending on the size of the project there were often many layers in between producing real signal distortion at each handoff.

It no longer needs to work this way. Nowadays a subject matter expert who knows the customer's industry, their language and understands their problems can build the working software together with the customer. They don't need to understand all the technical details of designing data structures, tuning application performance and choosing a tech stack. Some of those decisions will be embedded in the SDLC pipeline ensuring architectural consistency. Others will be checked and corrected (if needed) by an experienced senior engineer who reviews the solution at different checkpoints. In the end, the customer's effort of explaining the problem to a business-oriented person who understands their business is much smaller than in the traditional model. The risk of getting stuff wrong on the way is also reduced.

So, is AI the solution and answer to all the world's problems in software development? No, of course not. We should be thinking of AI as a set of tools that amplify whatever we're doing. If we are good at something, let's say writing Excel macros, we understand the underlying spreadsheet and know what we want to achieve – there is a high chance that we will be able to write new Excel macros much faster with AI. If we have no idea about Excel and try to modify a complex spreadsheet with macros without the full understanding of the current structure and the end goal, we are much more likely to produce a lot of mess, also much faster.

A popular saying in computer science is "garbage in, garbage out", which means that the quality of the output is always proportional to the quality of the input. Computers don't magically fix bad input.

Same applies to software and AI. Organizations and people that have many years of experience in designing and building great software now have the possibility to leverage AI and produce great software more efficiently. The proper structuring of this knowledge, guidance for the models, processes around it and professional human oversight allow us to offer new ways of working with customers to truly benefit from this revolution. AI will not replace those prerequisites, at least not in scenarios requiring anything more complex than a simple website. Nevertheless, there has never been a better time to build software.