Back to blog

Blog

AI makes software cheaper to build, but decisions are still hard

When development stops being the main bottleneck, product judgement, validation and learning become the real competitive advantage.

Published
  • AI
  • Product
  • Strategy
Technical desk with architecture diagrams and digital product decisions

For years, one of the main constraints when creating digital products was the cost of turning an idea into software. Even a first version required time, budget and specialised professionals to design, develop, test and deploy it.

That cost acted as a barrier, but also as a filter. Before committing weeks or months of work, companies had very practical reasons to debate priorities, reduce scope and ask whether a feature was truly worth the investment.

Artificial intelligence is weakening that filter.

Today we can write code, generate interfaces, prepare prototypes and automate tasks at a speed that would have been unthinkable a few years ago. This creates enormous opportunities: small teams can test ideas sooner, reduce repetitive work and solve problems that previously could not justify the cost.

But it also creates a trap: mistaking the ease of building something for confidence that it is worth building.

The bottleneck does not disappear: it moves

When one part of a system speeds up, the constraint tends to emerge somewhere else. If producing code becomes faster, the problem is no longer purely technical. The question changes from “can we build it?” to “should we build it?”.

AI can help us execute a decision, but it does not remove the need to make a good one. On its own, it does not know the complete context of a company, its customers, its operational constraints or the goals that justify an investment.

As execution becomes abundant, judgement becomes scarcer.

A team can generate more prototypes, run more experiments and add more features. Yet producing more does not guarantee learning more. If every idea automatically becomes part of the product, the likely result is an inflated roadmap, a more complex experience and a system that is increasingly expensive to maintain.

Code is not the full cost

A feature does not end when its code reaches production. From that point on, the team has to:

  • maintain and update it;
  • integrate it with the rest of the system;
  • explain it to the team and customers;
  • handle incidents and edge cases;
  • measure whether it is actually creating value;
  • absorb the complexity it adds to future decisions.

AI can reduce a significant part of the initial cost, but it does not erase the lifetime cost. In fact, the easier it becomes to add new pieces, the greater the risk of accumulating software that nobody uses or that makes the product harder to evolve.

The problem is not building quickly. The problem is building quickly without enough evidence that the result is worthwhile.

The feature factory

An organisation focused only on delivery can easily become a feature factory. Every request becomes a task, every task becomes code and every piece of code becomes a new permanent obligation.

Speed amplifies this behaviour. If creating a feature appears cheap, saying no becomes harder. But a collection of seemingly inexpensive decisions can produce an incoherent product and a platform that is difficult to operate.

There is an important difference between activity and progress:

  • Activity means producing more outputs.
  • Progress means reducing a meaningful uncertainty for the business or the user.

AI creates more value when it accelerates the latter.

From accelerating the roadmap to accelerating learning

The best application of AI in product work is not necessarily filling the roadmap. It is shortening the distance between a question and real evidence.

Before developing a complete solution, a team can use AI to:

1. synthesise interviews and identify patterns; 2. explore alternative solutions; 3. create functional prototypes in a few hours; 4. prepare user tests; 5. analyse results and formulate new hypotheses; 6. automate the disposable parts of an experiment.

This approach changes the unit of progress. Instead of measuring only completed features, a team can measure answered questions, eliminated risks and better-informed decisions.

Speed is no longer used simply to produce more. It is used to be wrong sooner, on a smaller scale and with room to correct course.

The capabilities that become more important

Understanding the problem

A technically brilliant solution can fail when it addresses a secondary or nonexistent need. Researching the user's context, motivations and constraints remains essential.

Prioritising clearly

When almost anything seems possible, teams need explicit criteria for deciding what deserves resources. Strategy is not a list of everything we could do; it is a choice about where to focus.

Designing small experiments

Not every hypothesis needs a complete feature. A conversation, simulation, mock-up or manual process may provide enough evidence to choose the next step.

Removing and simplifying

The ability to build must be matched by the ability to remove. A product improves through what it includes and through what it avoids accumulating.

Connecting technology and business

AI shortens the distance between intention and execution. That makes people who can translate business goals, real needs and technical constraints into sound product decisions even more valuable.

A practical framework before building

Before turning an idea into a feature, it helps to answer five questions:

1. What specific problem are we trying to solve? 2. Who cares about it, and how often does it happen? 3. What evidence suggests the solution will change a behaviour or outcome? 4. What is the smallest version we can use to learn? 5. What permanent cost will we add if we decide to keep it?

If the answers are weak, AI should not be used to accelerate construction directly. It should be used to find better answers. This is one of the situations where it can help us break through analysis paralysis.

The advantage is no longer building more

The democratisation of development is good news. It allows smaller teams to experiment, automate and create value. But it also makes executing a bad idea faster and easier.

The competitive advantage will not simply belong to whoever produces the most code or launches the most features. It will belong to those who learn sooner, understand the problem better and focus their ability to execute on the decisions that actually matter.

When anyone can build more, knowing what to build is valuable. Knowing what not to build may be even more valuable.

Have a project in mind?

Let’s turn your idea into a product that works

If this article connects with a challenge you are facing, tell me about the context. I’ll reply with a clear first assessment and sensible next steps.

Tell me about your project