Fixed Price
A concept first
- One or two days of audit, then a written concept.
- On that basis a fixed price instead of a day rate.
- The work still runs in iterations, and the concept stays current.
For twenty years software development has had two ways of working. A Pflichtenheft tells you what you will get and what it will cost, but it is written once, and everything after that is a negotiation. Scrum lets you change direction every two weeks, but nobody can tell you at the start what the finished thing will cost. Both compromises come from the same fact: writing and rewriting a specification was slow, manual work. That has now changed.
01 — The audit
One to two days, before anything is estimated.
I look at what you have: the code, the systems around it, the people who work with it, and what you actually want to come out at the end. We talk, and I record the sessions so Whisper can turn them into minutes the same day. No cloud services involved, entirely private. The concept is then built from what was said, not from what someone remembered a week later.
What comes out is a written concept: what the software has to do, for whom, in what order, and what it has to talk to. A Lastenheft or Pflichtenheft if you need it in that form, the same substance in a lighter shape if you do not.
02 — Why a specification is worth writing again
The document stopped being expensive.
A detailed spec used to age badly, because the day it was agreed was the last day it was cheap to change. So teams either froze it and argued about every deviation, or abandoned the idea and worked without a picture of the whole.
Drafting, cross-checking and rewriting a specification is now a matter of hours rather than weeks. Once that is true, the choice between planning and adapting stops being a choice. You can have a concept before anyone writes code and still turn when you need to.
03 — Iterations, still
A plan does not survive contact with reality.
That is how fixed-scope projects earned their reputation. After the first working version you will want adjustments. Features you asked for feel wrong once you have tried them. A supplier changes an interface.
So we work in iterations the way you would in Scrum: something running early, looked at together, corrected. The difference is that we are correcting against a concept we both agreed to, instead of discovering it while building.
04 — When something changes
The spec is rewritten, not annotated.
There is always exactly one current document describing what is being built. It is rewritten quickly and easily, so keeping it current is not a project of its own.
A change is a decision: something of comparable size comes out, or the scope grows. You see the effect before you choose.
Only with a current concept is a fixed price possible. If everything can change with nothing binding it, a day rate is the only instrument left.