Pricing Software Projects for EU Clients: Fixed-Price, Time-and-Materials, and Retainer Trade-Offs
Mispricing a software engagement is one of the fastest ways to end up in a situation nobody wants: margins eroded to zero, a client who feels overcharged, or a contract dispute that poisons an otherwise solid working relationship. Yet the conversation around software project pricing rarely goes deeper than "we do fixed-price" or "we prefer T&M." The real question is which model suits which type of work - and what the contract needs to say to protect both sides.
This post breaks down the three main pricing models used in EU software projects, when each one makes sense, and the risk implications that rarely get discussed until something goes wrong.
The Three Models at a Glance
Fixed-price means a defined scope, a defined deliverable, and a single agreed number. The client knows the total cost upfront. The vendor absorbs scope creep.
Time-and-materials (T&M) means the client pays for actual hours worked, typically at an agreed hourly or daily rate. Scope can flex; the client absorbs the cost of changes.
Retainer means the client pays a regular recurring fee - monthly is most common - for a defined level of availability. Work performed is drawn against that capacity.
Each model shifts risk in a different direction. Understanding who carries what risk is more useful than any general advice about which model is "better."
Fixed-Price: When It Works and When It Backfires
Fixed-price contracts work well when the requirements are genuinely stable. If you can hand a vendor a spec document, walk away, and expect to receive a working system that matches it - fixed-price is clean and predictable.
In practice, that scenario describes a minority of software projects. Requirements shift. Stakeholders change their minds after seeing the first build. Technical constraints surface that were not visible at scoping time. Every one of those changes either falls on the vendor (who absorbs the cost and erodes their margin) or triggers a change order process that grinds the project to a halt.
The EU-specific wrinkle: Under German and Austrian contract law in particular, the Werkvertrag (work contract) framework creates meaningful obligations around delivery of a specific result. A fixed-price engagement that is misclassified as a Werkvertrag - or correctly classified but poorly specified - can expose vendors to warranty claims for defects, even after handover. If you are pricing fixed-price work for German or Austrian clients, the contract language around acceptance testing and defect liability needs careful attention.
When fixed-price makes sense:
- Scope is exhaustively documented and both parties agree it is frozen
- The project is short enough (under 8-10 weeks) that requirement drift is unlikely
- The deliverable is well-understood and comparable to prior work (so estimating risk is low)
- The client explicitly needs budget certainty for internal approval processes
When it backfires:
- Requirements are loosely defined and "we will figure it out as we go"
- The client expects to make design decisions mid-project
- The technology stack involves meaningful unknowns
- The project is long enough that business priorities will shift before delivery
The classic failure pattern is a fixed-price contract on a fuzzy scope that turns into a protracted negotiation over what was "in" and what is a change request. Both sides lose.
Time-and-Materials: Flexibility at a Cost
T&M removes the scope-locking problem. The client can change direction, the vendor bills for the actual work done, and there is no incentive to pad estimates or hide problems to avoid change orders. For complex, evolving software projects - custom software development, platform builds, or any greenfield work where the product shape is still being discovered - T&M is often the more honest model.
The risk shifts entirely to the client. An open-ended T&M engagement with no budget guardrails can overrun significantly. Clients who have never run T&M projects often underestimate how quickly hours accumulate, particularly in the early phases where architecture decisions get revisited.
Managing T&M risk for clients:
Good T&M engagements have budget caps per sprint or per phase, regular cost-versus-budget check-ins, and a clear escalation process before any phase overruns. These are not the vendor's responsibility to impose - but a vendor who does not proactively surface cost signals is not serving the client well.
The EU tax and invoicing layer: T&M invoices across EU borders carry VAT implications that fixed-price invoices do not escape either, but the monthly rhythm of T&M billing makes it more operationally visible. Reverse charge applies to B2B services across EU member states, but the paperwork burden - particularly for vendors invoicing from Germany or the Netherlands into France or Spain - is real. Factor this into your invoicing cadence and make sure your contracts specify the tax treatment explicitly.
When T&M makes sense:
- The project has complex or evolving requirements
- The client wants ongoing input into prioritisation and direction
- The vendor and client have an established trust relationship
- The work spans a long timeframe (six months or more)
- Speed matters more than cost certainty
Retainer: The Model That Changes the Relationship
A retainer is not a project model - it is a relationship model. The client is not buying a deliverable; they are buying capacity and availability. This distinction matters enormously for how you structure the work and the contract.
Retainers work best for ongoing development partnerships: a team that handles a client's web application on a continuing basis, a consultant embedded in a product team, or a legacy code optimization engagement where the codebase needs sustained attention over time rather than a one-time fix.
The appeal for clients is predictability and priority access. They know the consultant or team is available to them each month. The appeal for vendors is revenue stability - monthly recurring income is easier to plan around than project-by-project work.
The common failure mode: Retainers collapse when the scope of what is "included" is ambiguous. If a client with a 20-hour monthly retainer starts treating it as a 40-hour engagement because they believe maintenance includes everything from bug fixes to new feature development, the relationship deteriorates fast. The contract needs to define exactly what the retainer covers, how unused hours are handled (carry-over or lost), and what triggers an out-of-scope conversation.
Retainer structures to consider:
- Capacity retainer: X hours per month, available for whatever the client needs, unused hours do not roll over. Simple and clean.
- Milestone retainer: Monthly fee tied to specific ongoing deliverables (e.g., monthly performance reports, regular deployments, on-call support with defined SLAs). Higher overhead to manage but clearer accountability.
- Hybrid: A base retainer for availability and support, with T&M billing for development work above a threshold.
When retainer makes sense:
- The client has continuous, ongoing needs rather than a discrete project
- The client values availability and responsiveness over pure output
- The vendor wants revenue predictability and is willing to manage capacity carefully
- The relationship is established enough that both sides trust the other to be honest about hours
Comparing Risk Profiles Side by Side
| Fixed-Price | Time-and-Materials | Retainer | |
|---|---|---|---|
| Who bears scope risk | Vendor | Client | Shared |
| Cost predictability for client | High | Low | Medium |
| Revenue predictability for vendor | Medium | Low | High |
| Suited to | Short, well-defined projects | Complex, evolving work | Ongoing partnerships |
| Contract complexity | Medium (change order process) | Low (rate + hours) | Medium (scope definition) |
| EU contract law exposure | Higher (Werkvertrag in DE/AT) | Lower | Lower |
Practical Guidance for EU Engagements
A few points that come up repeatedly when pricing work for EU clients:
Get the payment terms right. EU commercial clients - particularly larger ones in France, Spain, and Italy - often operate on 60-day or even 90-day payment terms by default. If you are accustomed to net-30, a T&M engagement with a large French enterprise can create a serious cash flow gap. Negotiate payment terms explicitly, and consider shorter billing cycles (bi-weekly for T&M) to reduce exposure.
Governing law matters more than you think. A contract between a German vendor and a Spanish client that specifies German law and German courts is worth something. One that does not specify governing law invites arguments about which jurisdiction applies. For cross-border EU engagements, this is worth a single paragraph in the contract.
Written change orders, always. In any model, verbal agreement on scope changes creates disputes. A simple email confirmation - acknowledged in writing by both parties - is the minimum. For fixed-price, a formal change order signed by both sides is worth the friction.
Discovery phases reduce fixed-price risk. If a client insists on fixed-price for a complex project, a paid discovery phase (T&M or a small fixed-price engagement) to nail down requirements before the main contract is signed significantly reduces risk on both sides. It also builds trust before the larger engagement begins.
Choosing the Right Model
There is no universally correct answer. The right model depends on how well-defined the scope is, who has more tolerance for financial risk, the duration and complexity of the work, and the maturity of the vendor-client relationship.
For a short, well-specified project with a client who needs a firm budget: fixed-price. For a complex platform build where requirements will evolve: T&M with sprint-level budget visibility. For an ongoing development partnership: retainer, with careful scope definition.
If you are working with a vendor or consultant and are not sure which model fits your situation, the conversation about pricing is also a signal about how well the vendor understands the nature of the work. A vendor who insists on fixed-price for vaguely specified projects is either very confident or not carrying their share of the risk thinking.
If you are evaluating pricing models for an upcoming software project - or renegotiating an existing engagement that is not working well - hello@wolf-tech.io is a good place to start that conversation. Wolf-Tech works with EU clients on custom software development, web application development, and tech stack strategy engagements, and can help you structure the engagement model alongside the technical work.