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

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.

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:

1. Client submits a change request — a formal document describing the modification
2. Impact analysis — the team estimates the cost, timeline, and risk impact
3. Options presented — the client sees trade-offs: add X, delay Y, or increase budget by Z
4. Approval or rejection — the client signs off on the adjusted terms before work begins
5. 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.