Two Thirds Less Investment: Where the Saving Comes From

I claim that on classic development projects we can cut the investment on the client side by roughly two thirds. That is a number you should not simply put out there without breaking it down. So here is the breakdown – including the places where nothing is saved.

First: where the number does not come from

It does not come from us working more cheaply. The day rate is not the lever.

It does not come from delivering less either. What stands at the end is the same software, which has to do the same things.

And it does not come from an accounting trick that shifts effort from the provider to the client. That would be the cheapest variant: offer less, call the rest "the client does that themselves" and celebrate the saving.

The number comes from the fact that a large share of the classic project effort simply no longer arises.

How a classic project is divided

Take a typical mid-sized undertaking at an SME. Roughly speaking, the effort splits into five blocks:

Analysis and design. Understanding what is needed, mapping processes, clarifying edge cases, defining the target picture and architecture.

Implementation. The actual build: data model, logic, interfaces, integrations, tests, documentation.

Coordination. Everything that arises because several people work on the same thing: alignment, handovers, status meetings, misunderstandings and their correction, waiting time between deliveries.

Go-live. Target environment, data protection, permissions, migration, training, launch.

Rework. Whatever surfaces in the first weeks after the start.

In the projects I used to guide, implementation was the largest block and coordination was the most underestimated one. Together the two regularly accounted for well over half of the total effort.

What falls away today

Implementation shrinks dramatically. That is the obvious part. When the data model and behaviour are described clearly, the build takes hours instead of weeks. Tests and documentation run alongside instead of appearing at the end as leftovers. Refactorings that used to be avoided on cost grounds are now so cheap that you simply do them.

Coordination shrinks even more. That is the part almost everybody overlooks. A large share of the effort in classic projects arises not from work but from the division of work. Five people who have to build the same understanding create effort that grows disproportionately with team size. When the same work is done by one person with AI support, that block disappears almost entirely. No handover, no alignment round, no waiting for somebody else's contribution.

Boilerplate disappears. Project setup, scaffolding, standard components, configuration – things that in sum consumed a surprising amount of time and now take minutes.

Rework goes down. Not to zero, but noticeably. Because the work is reviewed against the subject matter during implementation and corrections cost almost nothing, less ends up in production that does not belong there.

What stays – and what even grows

Analysis stays. Entirely. What a process really does, which rule genuinely applies and which is merely a historical leftover – no AI answers that. This work happens in conversation and in probing.

To be honest: it even grows in relative terms. Not in absolute hours, but in importance. When implementation costs almost nothing, sloppy analysis is the only remaining way to make a project expensive.

Review stays. Whether a solution runs technically is answered quickly. Whether it is factually right takes exactly as long as it used to. Saving here means saving in the wrong place.

Go-live stays. Determining the target infrastructure, clarifying data protection, setting permissions properly, setting up operations. None of that gets easier through faster implementation.

Operations stay. And they are a recurring item, not a one-off. Anyone drawing up an investment calculation without operations is calculating wrongly – more so today than before, because operations have grown as a share.

The calculation at its core

If implementation and coordination together make up the larger part of the classic effort and both largely fall away, while analysis, review and go-live remain, you land at roughly one third of the original effort. That is where the number comes from. No modelling magic, just two blocks disappearing.

What that means for you as a client: the price of a project today depends far more on how clearly your business is described than on how much functionality you order. Additional features are barely the cost driver anymore. Ambiguity is.

Where the two thirds do not apply

For the number to hold up, the counter-check belongs with it. It does not apply to undertakings whose effort never sat in implementation anyway – a system rollout, say, where ninety percent of the work consists of migration, organisation and training. It does not apply to heavily regulated environments where evidence and acceptance processes set the pace. And it does not apply when nobody on the client side has time to answer questions – then the bottleneck is the availability of knowledge, and no tool changes that.

Those limits are exactly the subject of the next article: where AI-assisted development does not work today.