A two-minute change-request protocol for fixed-fee web projects

AI assistance disclosure: This article was drafted with AI assistance and edited by Arelvia Studio. The workflow is presented as practical guidance; no client story or business outcome is claimed.

A fixed-fee web project usually does not lose its margin in one dramatic meeting. The loss arrives as a sentence that sounds harmless:

Could you just add this before launch?

The request may be reasonable. The failure is treating it as a to-do before deciding what happens to the existing commitment.

Teams often reach for one of two responses. They say yes and hope the schedule absorbs it, or they start an open negotiation in which one side lists everything that could be removed. The first creates unpriced work. The second creates anchoring: once one side names a concession, the other side reacts to it instead of making an independent decision.

Here is a small protocol that fits between those two failures.

1. Freeze one new request

Write the request as one observable outcome, not a bundle of implementation ideas.

Weak:

Make the launch page work internationally.

Better:

Add one English/French language switcher to the public launch page, with translated copy supplied by the client.

If the request cannot be written as one outcome, it is not a small change yet. Split it before discussing scope.

2. Freeze the remaining deliverables

Take a snapshot of what the fixed-fee project still promises. Do not add speculative extras and do not rewrite the original agreement. You need a bounded menu of real deliverables that have not already been completed.

For example:

• launch-day analytics dashboard;
• three-device QA pass;
• CMS handover video.

Security fixes, accessibility defects, and work already required by the agreement should not be offered as bargaining chips. The list is for genuine optional trade-offs, not for escaping existing obligations.

3. Let each side choose privately

Ask the agency and client the same question:

If this new request enters the fixed-fee project, which one remaining deliverable could leave without making the project unacceptable?

Each side chooses independently. Do not reveal rankings, rejected options, or who answered first.

This matters because visible choices change later choices. If the agency says “the handover video” first, the client is no longer evaluating the project from scratch. They are accepting or resisting the agency's anchor.

4. Reveal only an exact overlap

If both sides chose the same item, you have a candidate scope swap:

Add the language switcher; remove the CMS handover video.

That is not automatic approval. It is a clean proposal that both sides independently found acceptable.

If the choices do not match, reveal no rejected option. The result is simply: no mutual swap was found.

That failure is useful. It tells you the new request cannot enter for free under the current boundaries. The next step is to price a change order, move the request to a later phase, or decline it.

5. Write a short receipt

Record only what was agreed:

• the frozen new request;
• the deliverable leaving scope;
• the date;
• the people or roles authorized to accept the change;
• any schedule or acceptance-criteria adjustment.

Do not preserve everyone's rejected choices in the receipt. They are negotiation exhaust, not part of the agreement.

A compact implementation model

If you build this into an internal tool, the data model can stay small:

change_request
  id
  project_id
  requested_outcome
  candidate_removals[]
  status

private_decision
  change_request_id
  role
  selected_candidate_id
  locked_at

scope_swap_receipt
  change_request_id
  matched_candidate_id
  accepted_at

The important part is not the schema. It is the information boundary:

• one role must not read the other role's decision before locking;
• rejected choices should never enter the public receipt;
• a no-match result must not leak which option either side preferred;
• reopening a decision should be explicit and auditable.

You can run the protocol with two sealed notes and a neutral facilitator. Software is useful when the team needs repeatability, remote participation, and a durable receipt without asking a person to hold both private answers.

When not to use it

Do not use a scope swap when:

• the request is already included in the signed scope;
• the change needs a real price and schedule adjustment;
• the work fixes a security, accessibility, privacy, or contractual defect;
• one side lacks authority to change the agreement;
• there is no safe deliverable that can leave.

The protocol does not decide fairness or replace a contract. It only removes one source of negotiation bias and makes the no-overlap outcome explicit.

A reusable sentence

When the next “small change” arrives, try this before estimating implementation:

We can evaluate that addition without expanding the fixed fee. First, let us each choose privately which remaining deliverable could leave. If we independently choose the same item, we will write the swap. If not, we will price or defer the change.

That sentence changes the order of operations: boundary first, task second.

---

Commercial disclosure: ScopeTrade is a USD 20 one-time product from Arelvia Studio that implements this private choose-then-reveal workflow. The protocol above can also be run manually; the product does not amend contracts, price change orders, decide fairness, or guarantee agreement.