DEV Community: Janusz Kozioł

Scope Is Never Fixed — Why Specification Ambiguity (Not Scope Creep) Is the Real Fixed-Price Problem

Janusz Kozioł — Tue, 04 Aug 2026 12:56:21 +0000

Software projects fail on fixed-price contracts. This is not a controversial statement — the Standish Group's CHAOS report has tracked this for decades, showing that only 31% of software projects succeed on time and on budget, while 50% are challenged and 19% fail outright. But the conventional wisdom about why they fail — scope creep — misses the real problem.

Scope creep is a symptom. The real disease is specification ambiguity.

The Map Is Not the Territory

Paweł Brodziński, an experienced software delivery leader, captured this perfectly with a simple analogy. A specification is a map of the software you want to build. And as with any map, its representation of the terrain is necessarily imperfect. For a perfect map, it would have to be as large as the terrain itself.

"The only absolutely precise specification of a software project is the code itself. But if you already have that, why would you buy it?"

When you write "As a workspace owner, I can set administrative privileges to workspace members," two people reading that sentence will envision different things. One imagines a simple dropdown with three permission levels. The other imagines role-based access control with custom policies, audit logs, and delegation. Both are reasonable interpretations of the same text.

The PMI's research on communications complexity confirms why this happens: the number of communication paths grows geometrically with project size (n(n-1)/2), and every path is a channel where ambiguity can creep in. Even a simple conversation involves encoding, decoding, and filtering — two receivers can interpret the same message differently.

Why This Is Not Scope Creep

Scope creep is when a client asks for something new after the contract is signed. That's a well-understood problem with well-understood countermeasures: change requests, sign-offs, contingency buffers.

Specification ambiguity is different. It's not about adding new things — it's about both parties believing they agreed on the same thing, when in fact they didn't. The feature was always in the scope description. The problem is that the description was vague enough to accommodate two different interpretations.

The PMI reports that 37% of organizations cite inaccurate requirements as the primary reason for project failure. Note the word: inaccurate, not incomplete or changing. Requirements are inaccurate because they are inherently imprecise, not because the client keeps moving the goalposts.

This distinction matters because you cannot manage ambiguity with the same tools you use to manage creep. You cannot "sign off" on an interpretation. You cannot charge a change request fee for a feature that was technically in the spec — the client will rightfully refuse.

The Adversarial Trap

Here is where fixed-price contracts create their own destruction. When the price is frozen, the vendor and the client have opposite incentives regarding scope interpretation:

The vendor wants to interpret the scope as narrowly as possible — less effort means more margin.
The client wants to interpret the scope as broadly as possible — more features for the same price.

This is not a trust issue. It is a structural incentive problem. Both parties can be acting in good faith and still end up in a dispute, because they read the same paragraph and saw different things.

Brodziński calls this out bluntly: "When we freeze the price, we pit both parties against each other. Where there's no alignment, there's going to be no team play."

The result is a project that feels adversarial from day one. Every clarification call becomes a negotiation. Every feature discussion carries an undercurrent of "is this included or not?" The collaboration that great software requires — where the vendor challenges assumptions and the client iterates on their vision — never materializes.

How to Break the Cycle

If specification ambiguity is inherent and cannot be eliminated, the question becomes: how do you manage it explicitly?

1. Make Assumptions Visible

Every specification contains implicit assumptions. The trick is to surface them before the contract is signed. Instead of a single scope description, write two versions:

Core scope — what you are confident you both understand the same way.
Assumptions log — everything that is not explicitly stated, with clarifications.

For example: "User authentication included" is vague. "User authentication via email + password, with optional Google SSO (not included in base price)" is explicit about what is and isn't covered.

2. Use Variant Scope

Instead of one fixed scope, offer the client a menu of options. "Core" (what's included in the base price), "Plus" (nice-to-haves that can be added for an additional fee), and "Future" (features that should be revisited after launch).

This transforms ambiguity from a hidden risk into a visible choice. The client can see the wiggle room and decide consciously which parts to pin down now and which to leave open.

3. Model the Scope Before You Price It

A surprising number of agencies price projects based on a one-page brief and a gut feeling. McKinsey's research shows that large IT projects exceed budgets by 45% on average, and a significant portion of that overrun traces back to the gap between the brief and reality.

The fix is to invest in structured estimation before signing the contract. Break the scope down into components, assign effort ranges to each (not single-point estimates), and flag the components with the widest ranges — those are the areas where ambiguity is highest.

4. Keep Your Own Delivery History

Every project you deliver creates data about what your scope descriptions actually meant in practice. The PMI's framework for project management identifies "lessons learned knowledge bases" as a critical tool for improving estimates. Build your own library of past projects, compare what you estimated vs. what you delivered, and use that data to calibrate your future scope descriptions.

This is the single most effective investment an agency can make. After three or four projects, you will know exactly which phrases in your scope documents tend to cause interpretation gaps — and you can fix them proactively.

How Apropo Helps

Apropo was built by software agency founders who lived through this exact problem. The platform addresses specification ambiguity in three concrete ways:

Interactive quotes with live pricing. Instead of a static PDF, the client sees a web-based quote where they can toggle features on and off and watch the price and timeline change in real time. This surfaces interpretation gaps before the contract is signed — if the client expected a feature to be included and it's not on the list, they see it immediately.

Reusable component library. Your team's best estimates, scope definitions, and delivery histories become a searchable library. When you write a new scope document, you start from components that have been validated in real projects — not from scratch.

Variant scope (core vs. optional). The quote structure makes it natural to separate what's definitely included from what's flexible. The client sees the difference and can make an informed choice, turning ambiguity into a conscious decision.

None of this eliminates the fundamental problem of specification ambiguity — that is impossible. But it transforms it from a hidden risk that destroys trust into a visible factor that both parties can manage together.

Conclusion

The next time a fixed-price project goes sideways, resist the temptation to blame scope creep. Look instead at the specification itself. Was it really as precise as you thought? Or did both parties read the same text and envision different software?

The map is not the territory. The sooner you accept that, the sooner you can build processes that account for the gap — instead of pretending it doesn't exist.

FAQ

Q: Does specification ambiguity only affect fixed-price contracts?
A: No. Time-and-materials projects also suffer from ambiguous requirements. The difference is that the financial incentive to exploit ambiguity is much weaker in T&M, because the vendor is paid for actual effort. The adversarial dynamic is unique to fixed-price.

Q: Can better requirements documents eliminate ambiguity?
A: Not completely. As the map analogy shows, the only perfectly precise specification is the running code. You can reduce ambiguity significantly by writing detailed acceptance criteria, but you will never eliminate it entirely. The goal is to manage it, not to eliminate it.

Q: How do I know if my scope document is ambiguous enough to cause problems?
A: Try this test: give the same scope document to two different developers on your team and ask them to estimate it independently. If their estimates differ by more than 20%, your scope is too ambiguous. The same test works with the client — ask them to describe what they think they're getting in their own words.

Q: Is it better to avoid fixed-price contracts altogether?
A: Not necessarily. Fixed-price contracts are sometimes the only option — some clients require them, and some regulatory frameworks mandate them. The key is to enter them with eyes open: use variant scope, explicit assumptions, and structured estimation to reduce the ambiguity gap before signing.

Q: What is the single most impactful thing an agency can do to reduce specification ambiguity?
A: Build a library of your own past projects. Compare your estimated scope to what was actually delivered. Identify the phrases and assumptions that consistently caused interpretation gaps. Then use that knowledge to write better scope documents for the next project. Three to four projects worth of this data will transform your estimation accuracy.

Q: Can interactive quotes really help with specification ambiguity?
A: Yes. When a client can see exactly which features are listed and toggle them on and off, gaps in understanding surface immediately. A static PDF hides these gaps. An interactive quote makes them visible before the contract is signed, which is the only time you can fix them without conflict.

The Art of Range Pricing in Software Projects: A Practical Guide for Agencies

Janusz Kozioł — Tue, 04 Aug 2026 12:55:32 +0000

Every software agency has been here: the client asks for a price, you give a range (say $45k–$65k), and two things can happen. Either the client nods and you win the deal at the low end — or they get suspicious and ask "so you don't actually know how much it costs?"

Range pricing is often misunderstood. Used wrong, it looks like you're guessing. Used right, it's the most honest and professional way to price software projects — because anyone who gives you a single fixed number for an undefined project is either padding heavily or gambling with their margin.

This guide covers when to use range pricing, how to structure it, and — most importantly — how to present it so clients trust you more, not less.

Why Single-Point Pricing Is a Problem

A fixed price for an undefined project forces you into one of two positions:

You pad aggressively — add 40% contingency, quote $70k for a project you'd happily do for $50k. If the scope doesn't expand, the client overpays. If it does, you're protected. Either way, one party loses.
You guess lean — quote $50k based on your best assumptions. If the client adds features mid-project, your margin evaporates. The client thinks they're paying for X, you're building X+Y. Both parties end up frustrated.

A pricing range avoids both traps. It says: "based on what we know today, this project falls between $45k and $65k. Here's what needs to be true for the low end, and here's what would push it toward the high end."

That's not guesswork. That's transparency.

The Anatomy of a Good Pricing Range

Not all ranges are created equal. A useful range has three properties:

1. Width That Respects Uncertainty

The width of your range communicates how well you understand the project.

Range width	What it signals	When it's appropriate
< 15% ($50k–$57k)	High confidence	Detailed spec, similar past projects, known team
15–30% ($50k–$65k)	Moderate confidence	Clear brief, some unknowns in tech or integration
30–50% ($50k–$75k)	Low confidence	Vague brief, new domain, experimental approach
> 50% ($50k–$100k)	Too wide to be useful	You need more discovery before quoting

The 25% rule from the original article still holds: if the gap between low and high exceeds 25% of the mid-point, the range is too wide to be actionable¹. Either narrow the scope or invest in discovery first.

2. Clear Assumptions Behind Each End

A range without assumptions is hollow. Every pricing range needs:

Low-end assumptions: "This price assumes standard authentication (email/password), no third-party integrations, and 1 revision round on the UI."
High-end assumptions: "The high end accounts for social login integration, 2 API integrations, custom admin dashboard, and 3 revision rounds."

Without these, the client hears "$45k–$65k" and plans for $45k. With them, they understand that the range reflects scope choices, not your inability to calculate.

3. A Path to Narrow the Range

The best pricing ranges come with a roadmap: "Here's what we'd need to clarify to give you a tighter number." This turns the range from a weakness into a discovery tool.

"You want a fixed price? Great. Let's spend 2 days defining the scope precisely — here's what that looks like, and here's what it costs. Or we start with a range and narrow it as we go."

When to Use Range Pricing

Range pricing works best in specific situations. Here's the decision framework:

✅ Use a Range When

The scope has known unknowns. You understand the project type but not the specifics. You've built 10 similar admin panels, but this one has a custom reporting module you haven't done before. A range captures the uncertainty honestly.

The client is open to collaboration. Some clients want to be partners in defining the project. They understand that software is built iteratively and that a range reflects reality. These clients respond well to transparency — they'd rather know the risk than have it hidden in a buffer.

You're bidding against fixed-price shops. A well-communicated range is a competitive advantage. While your competitor slaps a single number on the table, you're showing the client exactly what drives the cost. Clients who've been burned by fixed-price overruns will appreciate the honesty.

You have historical data from similar projects. The strongest foundation for a range is "we've done this before, and here's what those projects actually cost." Even without sharing specific numbers, knowing your own past performance lets you set realistic boundaries².

❌ Don't Use a Range When

The client demands a fixed number and won't budge. Some clients — particularly large enterprises with procurement departments — cannot process a range. Their system requires a single PO number. In that case, give them a fixed price, but invest heavily in scope definition and change management upfront. The range is still in your head; it's just not on the paper.

You have no data at all. A range without any foundation is just two numbers you pulled from thin air. If you truly have no idea, don't guess. Do a paid discovery sprint first.

The range would need to be comically wide. If your best case is 20 hours and your worst case is 200 hours, the range is useless to everyone. You don't need range pricing — you need to clarify the scope.

The project is fully spec'd. If you have pixel-perfect mockups, a detailed PRD, and the tech stack is locked — and you've done this exact combination before — just give a fixed price. Range pricing doesn't add value when there's no uncertainty.

How to Present a Pricing Range (So Clients Trust It)

The words around the range matter more than the numbers.

The Wrong Way

"This project will cost between $45k and $65k."

The client hears: "I'll pay $45k." When you later say it's $58k, they feel cheated.

The Right Way

"Based on your brief, this project falls in the $45k–$65k range. Here's the breakdown:

$45k assumes standard user authentication, a straightforward admin panel, and no custom integrations. This works if your requirements don't change and the tech choices are straightforward.

$65k accounts for social login, two API integrations, and a more complex reporting module. This is the safe number if there are unknowns we discover during development.

Our recommendation: start at the $55k mid-point. We'll refine the scope together in the first sprint, and either number is within range. If we nail down the assumptions early, we might even come in under the mid-point."

This approach does three things:

Anchors the conversation around scope, not price
Gives the client agency — they see how their choices affect cost
Demonstrates competence — you've thought through the scenarios

The Advanced Move: Let the Client Explore the Range

The most effective way to present a pricing range is to let the client experience it themselves. Instead of telling them "$45k–$65k," show them an interactive breakdown where they can see how each feature affects the total.

This is where dedicated estimation tools transform the conversation. An interactive proposal lets the client toggle scope items — "what if we remove the custom reporting?" — and see the price update in real time. They're not taking your word for the range; they're discovering it themselves³.

When a client explores a pricing range interactively, three things happen:

They understand why the range exists (because scope choices drive cost)
They arrive at their own comfortable price point
They trust the number more because they helped build it

Common Pricing Range Mistakes

Giving the Range Without Context

The biggest mistake. "$45k–$65k" out of context feels like a guess. Always pair the range with the assumptions behind each end. Always.

Locking In the Low End Too Early

Clients will hear "$45k–$65k" and immediately ask for a contract at $45k. When the true scope becomes $55k, you're the bad guy. Solution: anchor on the mid-point. "Our initial estimate is $55k, give or take $10k depending on scope refinement."

Defending Instead of Explaining

When a client challenges your range, don't defend it — explain it. Walk them through the components, the assumptions, the historical basis. Defensiveness signals weakness. Transparency signals confidence.

Using Ranges for Everything

Not every project needs a range. Repeatable work — maintenance, support, clearly-scoped sprints — should be fixed price. Ranges are for uncertainty. Don't use them as a crutch.

Range Pricing in the Age of Interactive Proposals

The original article on this topic was written before interactive proposals became practical for most agencies. The landscape has changed.

Static ranges (emailed PDFs) have the problems described above: the client locks onto the low number, questions the high number, and the range becomes a negotiation point instead of a communication tool.

Interactive ranges change the dynamic. When a client can manipulate the inputs themselves — add a module, remove a feature, adjust the timeline — they see the range as a live system, not a static bracket. The pricing conversation becomes a collaboration.

This is the direction the industry is moving. Agencies that still send PDFs with a single range are competing against agencies that let clients build their own quote interactively. The gap in trust and conversion is widening.

FAQ

Q: What percentage should my pricing range cover?

A: Aim for 15–30% between the low and high end, centered on your best estimate. Below 15%, you're probably overconfident. Above 30%, you need more scope definition before quoting.

Q: How do I handle a client who only remembers the low number?

A: Always anchor the conversation on the mid-point, not the low end. Say "our estimate is $55k, with a range of $45k–$65k depending on scope." The mid-point is the default; the ends are the boundaries.

Q: Can I use range pricing with enterprise clients and procurement systems?

A: Enterprise procurement often requires a single PO number. In that case, do the range work internally, present a fixed number to procurement, but include clear change terms in the contract. The range protects you during delivery, not during the PO process.

Q: Is range pricing compatible with fixed-price contracts?

A: Yes. Use the range during the negotiation phase to define what's included. The fixed-price contract then covers a specific scope at a specific number within the range. The change request process handles anything outside it.

Q: How do I narrow the range as the project progresses?

A: After each milestone, compare actual effort against the range. If you're tracking toward the low end, confirm with the client. If toward the high end, flag it early. Use the narrowing range as a communication tool — it shows you're monitoring the project, not just the budget.

Q: What if a competitor gives a single fixed price lower than my low end?

A: Don't compete on price. The competitor's fixed number is either padded (client overpays) or aggressive (competitor loses margin). Explain what your range buys: transparency, realistic expectations, and no surprises. Clients who've been burned by under-quoted competitors will appreciate this.

Q: How do I build a component library to make my ranges more accurate over time?

A: Track every estimate vs actual hours. After each project, update your component database with the real numbers. Within 5–10 projects, you'll have reliable baselines for your most common modules. This is where estimation tools with reusable component libraries pay for themselves.

Summary

Range pricing is not a sign of uncertainty — it's a sign of honesty. A single fixed number for an ambiguous project is the real lie. A well-structured range, paired with clear assumptions and a path to narrow it, builds more trust than any padded fixed quote ever could.

The key is knowing when to use it, how wide to make it, and how to present it. Use the decision framework above. Pair your range with assumptions. Let the client explore it interactively when possible. And never, ever give a range without context.

The 25% rule is a heuristic, not a law. For highly complex or novel projects, 35–40% may still be reasonable — but only if you're transparent about why the range is that wide. ↩
Building your own historical database of project estimates vs actuals is the single highest-leverage investment you can make in pricing accuracy. Tools that let you save and reuse component libraries make this practical instead of theoretical. ↩
Interactive proposals with live pricing don't just help the client understand the range — they change the negotiation dynamic. Instead of haggling over a single number, you and the client collaborate on finding the right scope-to-price balance. This is what dedicated estimation and quoting platforms bring that spreadsheets and PDFs can't. ↩

How to Protect Your Margin When the Client Changes the Project After Approval

Janusz Kozioł — Thu, 23 Jul 2026 13:34:16 +0000

A developer on Reddit shared a story that every agency owner recognizes: client approved everything. The scope was documented. The price was agreed. Work started. Then — halfway through — the client asked to redesign half the features.

The developer faced an impossible choice: risk the relationship by refusing, or absorb the work for free, destroying the project's margin.

This isn't normal scope creep. This is a fundamental breakdown of the approval process.

Why "Approved Scope" Is an Illusion

The moment a client signs a fixed-scope agreement, a psychological shift happens. In the client's mind, they've made a purchase. They're now entitled to the best possible product — which naturally evolves in their imagination as development progresses.

The developer, meanwhile, treats the signed document as a boundary. For them, any work beyond that boundary is uncompensated.

This asymmetry is baked into every fixed-scope contract that lacks a change request process. The hidden cost of fixed-price projects isn't just the risk buffer — it's the inability to handle evolution gracefully.

Scope Creep vs. Fundamental Change

There's a difference between a client who keeps asking for "small additions" (classic scope creep) and a client who, after formal approval, requests a structural redefinition of the project.

Aspect	Scope Creep	Post-Approval Change
Pattern	Gradual, cumulative	Sudden, structural
Per-change impact	Small, but adds up	Large, often >20% of scope
Negotiation	Ad-hoc, hard to say no	Requires formal process
Root cause	Poor boundaries	Changed business need or buyer's remorse
Solution	Better scope definition	Change request workflow

The developer from the Reddit post didn't face scope creep. They faced a client whose business needs shifted (or who didn't fully understand what they approved). That requires a different tool: the change request.

Why Ad-Hoc Negotiations Are Worse Than No Process

When scope changes after approval and there's no formal process, every negotiation becomes personal. The conversation shifts from "what does this change cost?" to "are you being difficult?" or "don't you care about our project?"

This is losing position for the agency. You become the blocker, not the partner.

A formal change request process depersonalizes the conversation. Instead of saying "no," you say "here's what that change would mean for the timeline and budget." The process absorbs the tension, and both sides can look at trade-offs objectively.

How Interactive Proposals Reduce Post-Approval Risk

The best defense against post-approval changes starts before the contract is signed.

Present scope in variants. Show the client what they approved, what optional enhancements could look like, and what future phases might include. When a client later requests something they could have chosen during proposal review, the conversation reframes naturally: "This was in the optional tier — here's how we add it."

Explain the cost drivers upfront. When the estimation process is transparent, clients understand why changes cost what they cost. A dashboard integration that looks like "just adding a chart" may involve data modeling, API contracts, and testing across five states. Show that complexity upfront.

Include a change request clause in every quote. Even if you never use it, the presence of a formal change process signals professionalism. It says: "We plan for changes, which means we've thought about what happens when things evolve."

How a Change Request Workflow Protects Margin

When scope changes after approval, here's what should happen:

Client submits a change request — a formal document describing the modification
Impact analysis — the team estimates the cost, timeline, and risk impact
Options presented — the client sees trade-offs: add X, delay Y, or increase budget by Z
Approval or rejection — the client signs off on the adjusted terms before work begins
Version updated — the original contract gets an addendum; the scope baseline moves

This workflow does three things:

Protects margin. No work happens without confirmed compensation.
Preserves relationships. The client isn't asking for favors; they're making a business decision.
Creates data. Over time, you'll see which clients generate the most change requests — useful for future pricing and qualification.

The Role of Risk Buffers

Even with a perfect change request process, some changes slip through — the small ones that feel petty to formalize. That's where risk buffers come in.

A transparent risk buffer (typically 10-15% of project value) gives you room to absorb minor adjustments without margin erosion. The key word is "transparent" — the client knows the buffer exists and sees when it's consumed. This prevents the buffer from becoming a hidden tax on the client's budget.

For example, Apropo's approach to scope-based estimation includes built-in risk allocation that's visible to both parties from the start.

How to Track Change Patterns per Client

One of the most overlooked benefits of a formal change process is pattern recognition. After 3-5 projects, you can identify client behaviors:

Does this client consistently discover new requirements after approval?
Do their changes tend to expand scope or refine existing features?
How much buffer does this client type typically consume?

This data feeds back into your pricing and qualification. A client who generates 30% in changes should have a larger risk buffer built into their initial quote. A client who never changes scope might be a better candidate for fixed-price.

Checklist: Prepare Your Proposal to Survive the First Change Request

Before you send your next proposal, audit it for these items:

[ ] Does the proposal distinguish core scope from optional scope?
[ ] Is there a written change request procedure in the contract?
[ ] Does your quote include a transparent risk buffer?
[ ] Have you explained what happens when scope changes (timeline impact, cost recalculation)?
[ ] Is there a version history mechanism to track scope evolution?

If the answer to any of these is "no," your next post-approval change request will be an ad-hoc negotiation — and you'll lose margin.

Conclusion

Client approval is not the end of risk. It's the beginning of a shared journey through uncertainty. Without a formal change request process, every post-approval change is a margin crisis waiting to happen.

Build the change request workflow into your proposals before you need it. When the client inevitably asks for "just one more thing," you'll have a system — not a negotiation.

FAQ

What is a change request process in software development?

A change request process is a formal workflow for documenting, pricing, and approving any modification to the project scope after the initial agreement. It automatically recalculates the impact on budget, timeline, and margin before work begins.

How is a change request different from normal scope creep?

Scope creep is gradual, undocumented expansion of scope. A change request is a deliberate, documented proposal. The key difference is formality: change requests have traceable agreements, while scope creep is absorbed into the project silently.

How can I protect margin when a client asks for changes after approval?

Use a formal change request workflow that requires written approval before work starts, clearly documents the cost and timeline impact, and maintains a version history of all scope modifications. Interactive proposals with scope variants help clients understand trade-offs upfront.

What should a good change request form include?

A good change request includes: description of the change, reason for the change, impact on budget and timeline, risk assessment, alternatives considered, and signature fields for both parties. Every approved change becomes an addendum to the original contract.

Do change request workflows damage client relationships?

No — they protect them. Clients appreciate clarity. A professional change request process signals that you run a disciplined operation. Problems arise from ad-hoc negotiations and unspoken budget tension, not from clear documentation.