Fixed Price or Agile? The Honest Decision Aid

"What does the whole thing cost — fixed?" That is the most understandable question in the world when you commission a software project. And it leads to one of the most common wrong decisions in the mid-market. Not because fixed price would be bad. But because the choice between fixed price and agile is almost always made for the wrong reason: out of a desire for safety instead of out of the nature of the project.

This article puts both models honestly side by side — including the uncomfortable truth that the fixed price often sells you exactly the safety it cannot deliver.

1. What fixed price and agile really mean

Fixed price means: you describe in advance, as precisely as possible, what is to be built, and the provider names a fixed price for it. The risk of the estimate lies with the provider — apparently.

Agile means: you define the direction and the budget per time slice, build in short cycles, look at it after each cycle and steer. The risk is shared and made continuously visible.

The core of the difference is not the price. It is how you handle a single question: how certain are you today of what exactly you will need in six months?

If the answer is "very certain" — a clearly outlined, stable problem — then fixed price is a fair, sensible model. If the answer is honestly "not that exactly", then the fixed price sells you a safety that exists only on paper.

2. The uncomfortable truth about the fixed price

A fixed price requires a complete specification up front. No one can name a fixed price for something that is not described. That sounds like discipline — but for most projects it is an illusion.

Because the specification you write at the start is precisely the one you understand the least. You are describing software you have never used, for a process you only really think through while building it. Three things then almost always happen:

• The provider prices in the risk. A serious fixed price contains a risk surcharge — you pay for uncertainty, whether it materialises or not.
• Every change becomes a change request. As soon as you notice that you need something different — and you will — a renegotiation begins. That often poisons the collaboration.
• The provider optimises for "spec met", not for "problem solved". Under a fixed price it is rational to deliver exactly what is written, even when both sides have long known that it is not the right thing.

This is not an indictment of the fixed price. It is the honest description of what it is: a model that only works when the specification is truly stable. For a clearly outlined, bounded piece of software that is the case — and then the fixed price is excellent.

3. The uncomfortable truth about agile

Agile is not automatically the better model, and it is often abused just as much.

Agile without discipline is just expensive trial and error. If no one prioritises, if the budget is not monitored, if every sprint changes direction, then "agile" is just a pretty word for a project without a rudder.

Agile demands your participation. Under a fixed price you can, in theory, hand over the spec and wait. Agile only works if someone on your side regularly makes decisions and sets priorities. Anyone who does not have that time will be unhappy with agile.

Agile makes the budget transparent — and that is uncomfortable. You continuously see what things really cost. That is honest, but it feels less like safety than a number in the contract — even when that number is often fictional.

The honest point: agile shifts safety from "number in the contract" to "control in the process". For many mid-market companies that is unfamiliar — but with uncertain requirements it is the more honest and, in the end, cheaper variant.

4. The pragmatic middle way we often recommend

In practice, the best answer is rarely pure black or white. We frequently recommend a combination to mid-market customers:

Fixed price for the discovery. A clearly bounded, fixed price for the first phase: understand the process, uncover risks, define the first real increment. That is easy to estimate and gives you an honest basis for decision before you release the big budget.

Agile with a budget cap for the implementation. After that, build iteratively, but with a clearly agreed maximum budget and fixed steering points. You get the flexibility of agile and the predictability of a cap.

This model takes the worst from both worlds away and keeps the best: no fictional overall specification, but also no open barrel. It fits the logic we describe for serious projects in the guide to custom software development — deliver visibly early, uncover risks early.

If your project depends heavily on interfaces, this staging is especially sensible: interface risks only show up while building. More on this in API development in Munich. And if an old system is in play, also read Legacy modernization — there a pure fixed price is almost always the wrong choice.

More about our approach can be found on the page about custom software and app development.

Conclusion

Fixed price or agile is not a question of faith. It is a question of how certain you are today of what you need. Fixed price is excellent for stable, clearly bounded problems. Agile is more honest when the requirements only mature while building. The most common mistake is the choice out of a desire for safety instead of out of the nature of the project.

Sources

This article is based mostly on our own project experience from fixed-price and agile projects in the Munich area. Where we describe the agile model, we refer to its original definition; the primary sources are linked below. No external study statistics are deliberately cited.

• Our own project experience from fixed-price and agile projects for mid-market companies in the Munich area
• Manifesto for Agile Software Development — the original definition of the agile approach
• Principles behind the Agile Manifesto — why changing requirements are welcome
• Guide: custom software development — a serious project flow
• API development in Munich — why interface risks matter for the model choice
• Legacy modernization — why a pure fixed price is risky with old systems