Agile Fixed Price An Alternative to Hourly Rates and Traditional Fixed Bids

The Usual Models and Their Trade-offs

At Black Bridge, we work with different models depending on the project. Each has its place. But for a certain type of project, we’ve found a third way that often works better.

Hourly Rate: Flexible, but Risk on the Client

With the hourly rate model, the client pays for our time. This works well for:

• Ongoing support: When scope is hard to predict
• Consulting and reviews: Ad-hoc support, architecture sparring
• Small adjustments: When a fixed package would be overhead

The trade-off is clear: the client carries the budget risk. If something takes longer than expected, they pay more. That’s fair, as long as both sides understand it—and as long as we communicate transparently when efforts change.

We offer hourly rate projects and will continue to do so. It’s the right model for certain situations.

Traditional Fixed Price: Predictable, but Rigid

At the other end is the traditional fixed price. One project, one price, done.

The problem: for this to work, requirements must be crystal clear. In reality—especially with cloud and infrastructure projects—you rarely know everything upfront. You discover things during implementation. Priorities shift. The market changes.

With a traditional fixed price, this leads to conflicts. Every change becomes a negotiation. “That wasn’t in scope.” The focus shifts from finding the best solution to contract interpretation.

That’s why we rarely do traditional fixed prices for larger projects. Not because the model is bad—but because it often doesn’t fit the kind of projects we do.

The Agile Fixed Price: A Third Way

For projects that are too large for pure hourly billing but too dynamic for a traditional fixed price, we use the Agile Fixed Price. The concept comes from the book of the same name by Boris Gloger and André Häusling, and we’ve adapted it for our work.

The core idea: Budget fixed, scope flexible. Risk shared.

Instead of pricing an entire project as a lump sum, we work in packages. Each package has a fixed price. What gets implemented in that package is decided together—based on the current state, not assumptions from three months ago.

How the Price is Determined

At its core, we price complexity, not time. We work with story points—a unit that describes the effort and complexity of a task. At the start, we agree on a price per story point.

The rest follows from there: budget divided by story point price equals the amount of complexity we deliver. The backlog gets estimated, prioritized, and both sides know what’s realistic for the budget.

The key difference: The client pays for solved problems, not for effort spent. Whether a task takes us two hours or two days doesn’t change the price—and therefore doesn’t change the motivation to work efficiently.

How We Prioritize

Value first. What brings the biggest impact to the business? That comes first.

At the end of each iteration, we look together: What has changed? Which priorities have shifted? The backlog gets re-sorted—always following the principle that the most important thing comes next.

How We Execute

Discovery Phase (Fixed Price)

We start with a clear analysis. AWS account review, architecture assessment, cost structure. At the end, there’s a prioritized backlog: What are the most important topics? What provides the biggest leverage? And a first estimate in story points, so it’s clear what’s realistic within the budget.

Iterative Packages (Fixed Price per Package)

Then we work in iterations. Typically two to four weeks per package. Each package has a clear goal:

• AWS Security Audit and Quick Wins
• Infrastructure-as-Code setup with Terraform or CDK
• Cost Optimization: Reserved Instances, Spot strategies, Right-Sizing
• Migration: From Heroku to AWS, from VMs to containers

At the end of each package: a review. What did we achieve? What did we learn? And most importantly: What’s most important for the next package?

The Flexibility

This is where the difference from traditional fixed price lies. After each package, priorities can be adjusted. New insights from operations? A shifted deadline? A feature that turns out to be less important? The backlog gets re-sorted, and we do what brings the most value in the next package.

And because each iteration delivers a working result, the client remains free: pause, stop, or even switch providers. No half-finished state, no dependency. The project is in a usable state after every iteration.

Why This Works for Both Sides

For our clients:

• Clear costs per package, no surprises
• Something usable after each package, not “80% done”
• Freedom to adjust priorities without contract battles
• Risk distributed across small units instead of one mammoth project

For us at Black Bridge:

• We can focus on good work, not scope discussions
• Efficiency is rewarded—if we’re faster, we start the next package sooner
• The collaboration is based on trust and regular alignment
• We really get to know the client’s context

When to Use Which Model

At Black Bridge, we decide together with the client which model fits.

Hourly rate we choose for:

• Ongoing support and maintenance
• Consulting, reviews, architecture sparring
• Projects with highly variable or unclear scope
• Situations where maximum flexibility matters

Agile Fixed Price we choose for:

• Clearly definable projects with multiple phases
• Situations where budget certainty is important
• Teams that want to actively participate and prioritize
• Projects where we expect requirements to evolve

Traditional Fixed Price comes into question for:

• Small, clearly defined single deliverables
• Situations with very stable, documented requirements

When It Doesn’t Work

The Agile Fixed Price is no silver bullet. It fails when the basic prerequisites aren’t met.

Lack of participation: The model lives on the client defining tickets, participating in estimates, setting priorities. If this participation is missing—because no time, no interest, or “just handle it”—it doesn’t work.

Politics in estimation: Story points only work when both sides estimate honestly. If tickets are deliberately downplayed to squeeze more into the budget, or deliberately inflated to create buffer, trust breaks down. And with it, the entire model.

Unclear requirements without willingness to clarify: Complexity can only be estimated when it’s clear what needs to be built. If tickets remain vague and no one wants to sharpen them, every estimate becomes guesswork.

In these cases, an hourly rate model is often more honest—because it leaves the uncertainty where it belongs.

What Really Matters

The billing model is ultimately a tool. What counts is the collaboration.

The Agile Fixed Price works because it creates structure for trust. Small packages mean regular checkpoints. Regular checkpoints mean problems become visible early. And clear results after each package mean no one is left in the dark.

But it also requires something from the client: participation. Prioritization. Decisions. The Agile Fixed Price is not a “throw it over the fence” model. It works when both sides invest.