Two models of collaboration – and why we usually recommend the retainer at Operating Systems.
Why This Question Matters
Before we dive into architecture, technology, or features, a fundamental question arises: How do we work together? On a fixed price basis with defined scope? Or as an ongoing collaboration with a monthly allocation? Both models have their merits. But they fundamentally operate differently – and the choice impacts flexibility, speed, cost, and outcome.
How Fixed Price Works
In the fixed price model, a scope is defined before development: specifications, requirements, scope. What is written is built. What isn't written is not built – or only commissioned later through a formal change request process. The process:
- Requirements are documented in detail beforehand
- Based on the document, a fixed price is calculated
- Development follows the defined scope
- Changes are handled through change requests – with separate assessment and commissioning
- Acceptance occurs at the end of the project
Advantages:
| 💰 | Predictable costs – you know in advance what it will cost |
| 📋 | Clear scope – what will be built is documented |
| ✅ | Defined closure – there is a project end |
Disadvantages:
| 🔒 | Limited flexibility – changes incur extra costs and take longer |
| ⏳ | Long lead time – requirements must be fully defined before development begins |
| 📄 | High documentation effort – requirements documents, change requests |
| 🎯 | False security – the fixed price applies only to the defined scope, not to the outcome |
How Retainer Works
In the retainer model, the client books a fixed monthly allocation of developer days. There is no fixed scope in the traditional sense. Instead, prioritization occurs in short cycles: What currently has the greatest impact? What have we learned from the last cycle? What has changed?
Process:
- A monthly allocation of developer days is agreed upon
- Joint prioritization in regular meetings
- Development in short iterations with quick feedback
- Changes naturally flow into the ongoing work
- No formal project end – the system grows with the company
Advantages:
| 🔄 | Maximum flexibility – priorities can change at any time |
| ⚡ | Faster results – no months of upfront definition |
| 🎯 | Better outcomes – because the system grows from real feedback, not assumptions |
| 📉 | No change request overhead – changes are planned, not the exception |
| 🤝 | Genuine partnership |
Disadvantages:
| ❓ | Less predictable – you don’t know exactly which features will be finished in month 3 |
| 🔁 | Requires ongoing involvement – regular meetings are mandatory |
| 📊 | Outcomes depend on collaboration – without client input, nothing gets done |
Why Retainer is a Better Fit for Operating Systems
An Operating System is not a project with a start and an end. It is a living system that evolves with the company. And this is where the issue with fixed price lies:
You Can’t Know Everything in Advance
Operational systems are complex. The requirements only become truly clear when the team starts working with the software. When real data flows. When processes interact with the system in practice. A requirements document written before the first line of code cannot fully capture this reality – no matter how thoroughly it was created.
Changes Are Not Mistakes – They Are the Process
In the fixed price model, changes are a problem: change request, assessment, recalculation, approval. In the retainer, changes are the norm. Each iteration brings new insights. Every feedback makes the system better.
The best features in our projects are rarely those that were in the initial concept – but rather those that emerged from practice.
The System Is Never Finished
Companies change. Markets change. Requirements change. An Operating System must be able to adapt – not just once a year through a new project, but continuously. The retainer reflects this reality. Fixed price does not.
Typical Concerns – and Honest Answers
"Without a Fixed Price, I Have No Cost Control."
Yes, you do. The monthly allocation is fixed. You know exactly what you are investing per month. What changes is not the price – but the content. And you have a say in that.
"How Do I Know That Time Is Used Effectively?"
Through transparency. We work in short cycles with regular meetings. You see what has been created after each cycle. You help prioritize what comes next. And you can adjust course at any time.
"Fixed Price Gives Me More Security."
Fixed price provides you with cost certainty – not outcome certainty. You know what it costs. But you don’t know if the result actually matches your reality. Because reality has changed between the requirements document and acceptance. A retainer exchanges apparent security for true adaptability.
When Fixed Price Still Makes Sense
We are not dogmatists. Fixed price is the right choice when:
- The scope is truly clear and stable
- It is a defined individual project, not system development
- Our client needs a fixed budget release before starting
- The requirements are not expected to change significantly
In many cases, we start with a fixed price initial project – for example, developing the first stage (organization) – and then switch to the retainer. This gives both sides security at the beginning and flexibility in the further course.
The Summary
| Fixed Price | Retainer | |
| Scope | Defined beforehand | Develops continuously |
| Changes | Through change requests | Flow into the work naturally |
| Costs | Fixed for the scope | Fixed per month, flexible content |
| Flexibility | Low | High |
| Outcome | What is in the requirements document | What your company truly needs |
| Collaboration | Client → Contractor | Partnership at eye level |
| Suitable for | Defined individual projects | System development and continuous advancement |
Which model fits will be clarified together. In most cases, the retainer is the more natural way – because an Operating System is not a project, but a process.