Time and materials, fixed price or sprints? How we bill software projects

How a project is billed helps decide how well it goes. A model that does not fit the project creates friction - when estimating, with every change and finally on the invoice. Here are the models we work with, and when each one fits.

In short

• Time and materials within a budget range - flexible while goal and scope are still taking shape.
• Classic fixed price - only sensible when the scope really is fixed.
• Agile fixed price in sprint sizes - our preferred model for delivery: planned together every quarter, without pinning everything down upfront.
• The AI savings we show on request - in an offer with and without AI, or in a fixed price including AI.
• A share of the business case - when the value can be clearly quantified.
• Operations as a flat fee - derived from what came up over the past twelve months.

Time and materials within a budget range

At the start of a project - in consulting, in workshops, while clarifying things together - the scope is naturally open. Here we work on time and materials or with small fixed prices. We name the budget range we expect to land in and bill the actual effort.

The advantage: you do not have to release a large budget before it is clear where things are heading. And you decide anew after every step how to continue.

The classic fixed price - and its catch

A fixed price gives budget certainty. To be sound, though, it would need everything to be settled upfront: the whole design, all requirements, every interface. In software development this is rarely feasible - requirements change as soon as the first results are on the table. Anyone who still pins everything down upfront pays twice: once for the specification and again for every change afterwards.

For clearly scoped packages with a stable scope, the classic fixed price is still a good choice.

Agile fixed price: sprints in T-shirt sizes

For delivery we prefer fixed sprint sizes - S, M, L, XL, XXL. Each size stands for a clearly described scope and has a fixed price. It follows from the roles your project needs - such as development, testing, architecture or design. From these sizes we put together the right sprints.

This is how it works:

1. Plan quarterly: you say what you want to deliver in the next quarter.
2. Estimate together: the team estimates with you how much sprint capacity the topics need.
3. Book sprints: this gives the matching sprint sizes - and with them the price for the quarter.

At its core this is estimating and billing by story points, just one level coarser. You don’t get lost in details that change in reality anyway, and you only estimate for the next sprints, not the whole project. The commissioning can breathe, the billing stays predictable.

Sprints can also be commissioned in parallel when several teams work on different tasks in the same context. An example: a result is currently being validated by another department. For this, a small sprint runs that mainly needs time until delivery, but little effort - coordination, questions, rework. In parallel, a second team develops new features in a larger sprint.

When something changes during a sprint

We work along the lines of Scrum. We prepare the scope of the next sprint before the sprint change - following the priority you set in the backlog. In sprint planning you see what the team has taken on and what is realistically achievable; you confirm the plan or swap individual tasks.

• If something new comes up during the sprint, we swap it for tasks of comparable effort that have not been started yet. Anything beyond that we plan into the next sprint according to your priority - nothing important waits longer than one sprint.
• During the sprint you are involved and know where things stand. There should be no surprises in the review.
• In the sprint review we show what was delivered - and if something did not work out, why. With the review the sprint is accepted, unless you raise something.
• If a shortfall is on us, we deliver the rest free of charge.

If a project needs more capacity for the long term, we provide it quickly - from our own teams and via SII Group’s nearshore and offshore centres. We only involve teams outside the EU with your consent (where your data is kept); export-controlled and classified work we carry out exclusively with authorised staff in Germany or the EU. New colleagues still need access and onboarding. The earlier we plan together and the sooner access is in place, the sooner they are productive.

Where the AI savings end up

When AI speeds up delivery, you should be able to see it. Two ways:

• Offer with and without AI: we calculate the classic approach and the approach with AI and show the savings. You decide which offer to commission.
• Fixed price including AI: the price is set. If it goes faster, we benefit. If it takes longer, it does not cost you more - the risk sits with us.

How large the savings realistically are depends heavily on the task; we show the range in Agentic AI: 85% on the slide, 36% at best.

A share of the business case

Some projects have a clearly quantified benefit - lower costs, faster processes, more revenue. Then we can work out together when the project pays off for you. We deliver it and receive an agreed share of the savings when the result is right. We agree the metric, baseline and measurement period together before the project starts - so there is no dispute afterwards about what counts.

The price then follows the value, not the hours - and we share your goal.

Operations as a flat fee

Operations is an ongoing task. Sprints would work here too, but we prefer to agree a flat fee. It follows what actually comes up in operations: together we look at the past twelve months - which roles were needed, how many requests and tasks were handled - and derive the effort from that. This way operations fits into the same billing concept as further development.

Which model when

Which model fits your project we clarify in the first conversation.