Sometimes the software you don't build is actually more valuable than the one you do.

You can also read the original article on our Medium:
https://luisyanguas22.medium.com/sometimes-the-software-you-dont-build-is-actually-more-valuable-than-the-one-you-do-503f7cc39adf

When we hear about someone developing a new software, there is quite often something that sounds strange...The flow is most of the times very similar. Basically, a company decides it needs a new system and gets together an action plan. They create a list of requirements, start with uncountable meetings and concept designs, and then developers start writing code and adding features as it goes. The project then gets bigger and while usually everyone feels productive, nobody actually stops to ask the most important question: Do we actually need to build all of this?

And even if it might sound like an obvious question, this in practice is one of the hardest and most useful questions to ask for the simple reason that software development has a quite natural tendency towards building new things, and when a development team is hired to create software, this creation process in itself feels like progress when sometimes it's actually not. In fact, some of the best tech decisions are the ones that result in less software, not more.

We can mention many examples about that, but maybe one is in the car industry, when Henry Ford understood something similar more than a century ago when he first introduced the Model T back in 1908. Ford was not looking to create the most customizable car in the world, instead he wanted a car that was affordable, reliable and relatively simple to build. The famous story about customers being able to choose any color “as long as it is black” became a symbol of this philosophy, and the reality was slightly more interesting because Ford's production system deliberately reduced variation because standardization basically made manufacturing much more efficient.

Ford was not selling fewer features because he couldn't imagine more features, he was instead making a deliberate decision about what actually mattered, and that difference is what also applies to our subject and what is incredibly relevant to modern software development.

Today, and specially with the last crazy AI model boom, companies can build almost anything, and even small entrepreneurs can dream with things that just a couple of years back would be financially impossible for them...Cloud platforms are everywhere, APIs make integrations way easier, AI can generate code in seconds and development models allow teams to create quite sophisticated apps faster than ever. The technical limitation is increasingly disappearing at a very high speed, but at the same time what many people don't realise is that the business limitation is actually not.

So instead of being tempted to jump on the development wheel without asking ourselves too much, companies should be asking themselves more than even if they actually need X or Y software or platform, and this is particularly important when developing custom software.

A clear example we often have seen is in the logistics sector. Usually, when companies are looking to build something that improves their business, they kisckstart an very analytical process where they Imagine a large number of features. Advance dashboards, mobile apps, automated notifications, optimisation for routes and trips, customer web portals, document or statistics management, predictive analytics, AI recommendations and a long etc. None of these requests sounds of course unreasonable as they are basically the tools that had traditionally made the great difference traditionally in this industry over the last years, but when you put all those requirements together you suddenly realise that the company isn't building a solution to a specific problem but instead is building an entire software universe around the business, and that is where projects become dangerous.

The more features a system has, the more complicated and expensive it becomes to design, test, maintain, secure and evolve, because basically in a system of this kind every new feature interacts with something else, every integration creates another dependency, every screen eventually needs updating and every workflow has an exception. Complexity has a tendency of multiplying quietly and of course complexity is very expensive, so the company needs to really think twice if that high expense is needed by looking at the cost reduction or the benefits the system generates when compared to its development and running costs.

One of the most common problems in software development is that teams often measure progress by what has been built rather than by what has been achieved. many people see ten or a hundred features or screens as something intrinsically good, or a new mobile app as something better in itself, but what if customers are still waiting two days for an answer? Or what if employees are still copying information between systems or the sales team still cannot see the information it needs? What if the new app saves five minutes in one process but creates three new administrative tasks somewhere else?

The software may be basically technically successful and commercially disappointing, and this is actually not a new problem. Research into software project success has repeatedly shown how difficult it is to define success simply through time, budget and functionality. A project can be delivered according to its original specifications and still fail to create the expected value for the organization, and this is the reason why good software development starts before development.

The most valuable work can happen in conversations where nobody is writing code and where people is wondering things like the real problem they want to solve, who actually has the problem, how often this problem happens, the cost that the specific problem is bringing today, etc. These questions are not signs that a software development company is reluctant to work, it's actually sometimes quite the opposite. They are signs that the company understands the cost of building the wrong thing, and the value of building the correct thing or actually don't build anything at all.

There is another fantastic historical example that came up with Apple and the Iphone...The first iPhone did not contain every feature that smartphones would eventually have later on...Apple made a series of choices about what the product should be and what it actually should not be. The product was great not because it did everything, but because the pieces worked together around a very clear experience. And that is an important lesson for custom software.

A great application does not need to impress everyone in the very beginning, but it needs to solve the right problem extremely well, and this is also where an experienced software development partner can create value that is easy to underestimate.

Clients sometimes think the value of a development company is the developers themselves, but they are not. Developers are essential, of course, but the greater value comes from combining technical experience with business understanding.

A good technology partner can look at a requirement and say they can build that, but a great one can sometimes say that while they actually can build that, they are at the same time not sure you should. And then look into it.
That conversation can save months of development, thousands of hours and a considerable amount of money. And of course it can also lead to a better product.

The irony is that saying “no” to features can actually make a software project more ambitious because it forces everyone to focus on the outcome. Instead of asking for a dashboard, you ask what decision the dashboard is supposed to improve, and instead of asking for an integration, you ask what problem the integration is supposed to eliminate. And those questions can be what actually changes the entire software development process.

All the above is becoming even more important as AI makes software development faster, because when creating software becomes cheaper and faster, the temptation will be to build more of it and companies will get more dangerously confident. More features, more experiments, more internal tools, more automation...But faster development does not automatically create better software, it only allows us to make decisions faster, while good decisions can produce enormous value and bad decisions can produce enormous amounts of software.

The companies that benefit most from technology will not necessarily be the ones that build the most applications but instead it will be the ones that become exceptionally good at deciding what deserves to be built, and sometimes that means developing a sophisticated custom platform, some other times it might mean integrating two existing systems, or sometimes it would be automating a single painful process. But as said, sometimes it might also mean building nothing at all!