Fixed-Scope Contracts Are a Recipe for Disaster: Why Shared Risk Is the Smarter Way to Build Software

It starts with a nod. A handshake. An agreed scope. Then the client asks for “just one more field” on the dashboard. Then a different kind of login. Then “we should probably reconsider the database structure.” At the end of the project, the builder has delivered 40% more functionality than the contract states — for the same price.

This isn’t a story about difficult clients. It’s about a broken contract structure.

Software development is fundamentally uncertain. Fixed-scope contracts treat it as if it were a construction project with known materials, known timelines, and no surprises. That mismatch is why builders eat costs, quality suffers, and client relationships turn adversarial.

The Contract Marcus Turned Down

A recent LinkedIn post from developer Marcus Rydberg went viral for a reason. Marcus turned down a contract he actually wanted — because the fixed-scope terms put all the risk on him. His honest assessment: “If that risk isn’t shared, someone ends up underwater. Usually the builder.”

He’s right. And his post resonated because every developer and agency owner has been in that position. You want the project. You have the skills. But the contract’s terms guarantee you’ll either lose money or cut corners.

Construction projects have been around for millennia. And for good reason, they developed sophisticated risk-sharing mechanisms over that time:

General contractors carry contingency budgets (typically 10-15% of project cost)
Change orders formally document every deviation from the original plan, with clear cost and timeline impacts
Subcontractor quotes are backed by material takeoffs and known labor rates
Owner’s contingency covers unforeseen conditions discovered during construction

Software projects, by contrast, are often treated as knowable from the start. But codebases are not blueprints. Dependencies shift. Technologies evolve. User testing reveals assumptions that were wrong. A fixed-scope contract for software is like a construction contract that forbids change orders — it assumes the ground won’t shift, even when you’re building on sand.

How Fixed-Scope Creates Perverse Incentives

When the builder assumes all financial risk for an uncertain outcome, behavior predictably distorts:

Scope inflation without compensation. Every “small tweak” from the client is hard to say no to — the relationship matters. But the compounding effect of 10 small tweaks can wipe out an entire project’s margin. According to industry research, scope creep erodes an average of 23% of project margin on fixed-price engagements.

Quality tradeoffs. When the budget runs out but the scope remains fixed, the only lever left is quality. Refactoring gets skipped. Tests become sparse. Technical debt accumulates. The project ships, but the codebase is fragile.

Adversarial client dynamics. The client naturally wants more for their fixed price. The vendor wants to deliver less. This fundamental misalignment turns every conversation into negotiation — not collaboration.

Inability to pivot. Discovery happens during development. Fixed-scope treats discovery as finished before code starts. When you learn something that suggests a better approach, changing course carries a financial penalty that makes it unattractive — even when it’s the right thing for the product.

How It Should Be Done: Shared-Risk Contracts

The alternative isn’t “just use T&M” — that shifts all risk to the client. The alternative is intentional risk distribution through several concrete mechanisms:

Transparent Cost Ranges as a Starting Point

Before any contract is signed, both sides should agree on a realistic budget range. Instead of hiding risks, show the client what drives the cost: core features, risk buffer, optional scope. When the client sees “business platform: $8,000 core + $4,000 risk buffer + $13,000 options,” the conversation shifts from “is this too expensive?” to “what scope fits our budget?”

This is how Apropo works — every proposal breaks down costs transparently so both sides know exactly what they are agreeing to.

Risk Buffers, Not Padding

Instead of a single price, quote a base scope plus a transparent risk buffer (typically 15-25% for custom development). This isn’t padding — it’s honest about uncertainty. If the buffer isn’t consumed, the client gets a credit. If it’s needed, no one fights over who pays.

Scope Variants

One of the most effective techniques is presenting scope in layers:

Core scope: what must be built to deliver value
Phase 2 options: what can be added after validation
Nice-to-haves: what the client wants but doesn’t yet need

This gives the client control over their budget without forcing the vendor to eat overruns. It’s the same logic why IT estimation should never be treated as a price guarantee.

Formal Change Request Workflow

When scope changes after approval — and it will — there must be a documented process that automatically recalculates the impact on price, timeline, and margin. Without it, every change is an ad-hoc negotiation where the vendor is at a disadvantage.

How Apropo Helps

Apropo provides the infrastructure for shared-risk contracting:

Transparent cost breakdowns give both sides a clear picture of what drives the price
Risk buffers are built into quotes transparently, not hidden as padding
Interactive proposals let clients see scope variants (core vs. optional vs. future) before signing
Change request workflows formalize every post-approval scope change with automatic margin impact calculation
Version-controlled quotes track how scope evolves from initial proposal to final agreement

The goal isn’t to eliminate risk — that’s impossible in software. It’s to distribute risk fairly so both sides can collaborate instead of negotiate.

When Fixed-Scope Makes Sense

For honesty: fixed-scope isn’t always bad. It works when:

The scope is genuinely well-defined (not “we think we know”)
The project is small enough that uncertainty is manageable (under $10,000 typically)
The deliverables are productized — a standard website package, a known integration
Both sides have worked together before and trust is high

But for custom software development above that threshold, fixed-scope is a gamble. And the house always collects.

Conclusion

The next time a client insists on fixed-scope for a complex project, resist the urge to nod and accept the risk. Instead, break down the costs transparently: what the risk buffer covers, what optional scope exists, and how a shared-risk contract protects both sides.

Good contracts aren’t about assigning blame when things go wrong. They’re about ensuring that when things go right — and they will — both sides feel like they won.

FAQ

What is the main problem with fixed-scope contracts in software development?

Fixed-scope contracts transfer all project risk to the builder. When requirements change or hidden complexity emerges — which they always do in software — the vendor absorbs the cost, creating adversarial dynamics and incentivizing corner-cutting.

What is a shared-risk contract model?

A shared-risk model distributes project uncertainty between client and vendor through mechanisms like milestone-based payments, time-and-materials pricing with caps, transparent scope variants, and formal change request processes that adjust budget and timeline when scope changes.

When does it make sense to use a fixed-scope contract?

Fixed-scope can work for well-defined, small-scale projects with stable requirements — simple websites, integrations between known systems, or productized services with limited customization. For anything with uncertainty, shared-risk is more realistic.

How do you justify pricing without market data?

Use your own team’s delivery history. After each project, document what tasks actually took and what was underestimated. Over time, you build an internal reference library that’s more accurate than any external benchmark because it reflects your team’s actual velocity.

How can agencies transition from fixed-scope to shared-risk contracts?

Start by adding risk buffers to quotes, introducing scope variants (core vs. optional), implementing formal change request workflows, and making your costs transparent to the client. Tools like Apropo automate these mechanisms.