Your Crypto Client Wants ‘One Small Change’: How to Handle Scope Creep

Imagine your studio is finishing a crypto project's launch page. The English version goes live on Friday. On Tuesday, the client sends a Telegram message:

“Our Spanish-speaking community wants a version too. Can you add a language switch before launch? Should be one small change.”

You can already picture the switch. You have not yet seen the translated copy, checked the longer headings or found time for another review.

To handle scope creep, compare the request with what you agreed to deliver, explain its effect on the work, and get a clear decision before starting the addition. First, check whether it is an addition at all. Fixing your own mistake and supplying an extra deliverable deserve different conversations.

The studio, messages, fee and schedule below are illustrative. They show how to make a decision explicit, not a real client result or a market-rate recommendation.

Check what you actually promised

Open the approved proposal and the messages that clarified it. Look for the deliverables, acceptance criteria, revision allowance, exclusions and person authorized to approve changes. An internal estimate alone does not establish what the client was promised.

For this example, the agreed job is one English launch page using approved copy, a responsive layout and a button linking to the project's existing app. It includes one consolidated copy-and-style review round. Additional languages and app functionality are excluded. The client has that scope in writing.

Now compare three requests against the same promise:

Client request	What it means under this agreement	Your next move
“The app button does not work on mobile.”	The delivered page fails an agreed function.	Investigate and correct the defect. Do not present the promised working button as an optional paid upgrade.
“Can we change this headline?”	A copy edit in the included review round, assuming it does not change the agreed page structure.	Include it in the consolidated feedback and confirm the revised wording.
“Can we add a Spanish version?”	An additional language and another version to implement, review and maintain.	Clarify the required result, then assess the change in scope, fee and schedule.

The number of words in the request tells you little about the work behind it. A short message can describe a new deliverable. A long bug report can describe work you already owe.

There are two uncomfortable exceptions worth facing early.

If you underestimated the agreed English page, that is not evidence that the client expanded the scope. Keep that delivery problem separate from a genuinely new request. The pricing decision and the scope decision need their own facts.

If your proposal just said “complete launch website,” the boundary may be unclear. Check the earlier sales conversation and ask what the client understood. Agree a fair written clarification; do not invent an exclusion after the request arrives. For future jobs, the one-page service offer guide helps turn a broad promise into deliverables and acceptance criteria.

Send a reply that keeps the request open

You do not need a finished quote to acknowledge the client. You do need wording that separates receiving the request from accepting it.

For the Spanish-page example, an initial reply could be:

Thanks for raising this. Is the goal to give the Spanish-speaking
community the same launch information, with the app link staying as it is?

The agreed Friday delivery is the English page. I will check the work
needed for a Spanish version and send you the fee and timing options
by 16:00 UTC today. Who will supply and approve the Spanish copy?

That question about the outcome matters. The client may only need a Spanish announcement linking to the English page. Or they may expect a fully translated app journey. Those are different requests, even if both began with “a language switch.”

Choose a response time you can meet. If you need technical discovery, say what you need to inspect and when you can return with a reliable estimate. A quick acknowledgment should not become a rushed delivery promise.

The Association for Project Management's change-control guidance separates recording a request, evaluating its effects, deciding what to do, and updating the plan when approved. A small studio can apply that sequence in one shared document and a clear approval message.

Estimate everything the addition requires

In our example, the client confirms that the request is one Spanish version of the launch page. The app itself will stay unchanged. The client will provide and approve the translation.

That removes translation production from the studio's work. It does not remove implementation and review.

Before quoting, the delivery lead checks how the Spanish page and language selector will work, how the supplied copy fits the existing layout, which links remain unchanged, and which mobile and desktop checks must be repeated. The estimate also includes coordination, one consolidated review and publication.

Have the person doing the work assess it. Then check the calendar as well as the effort. A task requiring several hours may still miss Friday if the developer is finishing the English page and the client's reviewer is unavailable until Monday.

For the fee calculation, use the Web3 service pricing worksheet and worked example. Here, the important distinction is between knowing what the change costs and deciding when the team can deliver it.

Do not quote a fixed addition while a material dependency remains unknown. If nobody has approved the Spanish text, specify the copy limit and delivery condition in the proposal. If the technical approach itself is uncertain, agree a bounded scoping task first, including its cost if applicable, rather than guessing a final implementation fee.

Offer choices you can actually deliver

Once you understand the work, return with feasible choices. You are helping the client choose a trade-off, so connect each option to what they care about.

Keep the Friday English launch and add Spanish afterwards. This protects the agreed launch scope while creating a separate delivery date for the additional page. It only works if the original launch can proceed independently.

Launch both languages together on a revised date. Reassess the combined work and ask the client to approve the revised milestone and fee. A larger budget does not, by itself, create reviewer availability or extra days before Friday.

Consider a swap if something genuinely replaceable remains. Name the deliverable being removed and compare its remaining effort and dependencies with the addition. Do not offer a cost-neutral swap until you have checked it. Removing a finished section will not recover the time already spent building it.

In this example, the delivery lead confirms that an approved Spanish version can be added the following week. The client prefers to keep Friday's English launch. That preference gives you a direction; the exact scope and approval still need recording.

If the client says, “We have no extra budget,” the agreed English launch remains one option. A smaller Spanish announcement may be another, if someone can produce and approve it. Do not quietly turn “no extra budget” into “the studio will absorb an undefined second deliverable.”

Likewise, do not push a larger package merely because an expansion opportunity exists. A separate conversation about additional services for an existing client can happen when that service has a clear purpose. This conversation has a narrower job: decide what happens to the current delivery.

Put the decision where the delivery team can use it

The approval record should answer the questions someone would otherwise have to reconstruct from chat. It can be short, but it needs to be specific.

Here is a completed illustrative change proposal, ready for approval. The $600 fee and all times are example terms, not a recommended price or standard turnaround.

Field	CR-01: Spanish launch page
Status	Proposed; additional work has not started.
Original delivery	English launch page on Friday, with the agreed existing-app link and review round.
Requested outcome	Spanish-speaking visitors can read the same launch information and reach the existing app.
Added work	One Spanish page using the existing design, up to 800 supplied words, plus a language selector. Implementation, layout checks, one consolidated copy-and-style review and publication are included.
Outside this addition	Translation writing, app localization, new app behavior, another language, ongoing copy updates and changes to the approved page structure.
Client input	The named client project lead supplies approved Spanish copy by Monday 12:00 UTC after the English launch. The client owns linguistic approval.
Fee	Fixed additional fee of $600 for this defined addition; original project fee unchanged.
Schedule	Spanish preview by Tuesday 12:00 UTC; consolidated client feedback by Tuesday 16:00 UTC; publication by Wednesday 12:00 UTC, subject to the agreed inputs and approval.
Acceptance	Spanish copy matches the approved source; the selector opens the intended language page; the agreed app-link destination works on both versions; no clipped headings or horizontal overflow at the example's agreed 360px and 1280px viewport widths. Client project lead approves the preview and final wording.
Approval route	The project lead named as change approver in the original agreement confirms CR-01, fee, schedule and responsibilities through the agreed approval channel.
If inputs or review are late	The Spanish publication slot must be reconfirmed against team availability. The independently deliverable English launch remains on its agreed plan.

This is an operational example. Use the approval and payment arrangements already agreed for the actual project; the record does not establish legal rights by itself.

The requester and approver may be different people. A community manager can identify a useful addition without having authority to approve its cost. Route the decision to the named approver instead of asking the developer to infer permission from a busy group chat.

Ask for a reply that identifies the change and its terms. An emoji or “looks good” beside a screenshot can leave the budget and schedule unresolved. Once approved, record who approved it and when, update the task list and delivery dates, and give the team the same version of the decision.

Continue the unaffected agreed work where feasible while the addition awaits approval. If the request changes a shared dependency and blocks that work too, explain the impact promptly and agree a revised plan. Do not silently promise that every original date survives every change.

At review, use the recorded acceptance criteria. A selector opening the wrong page is a defect to correct. A request for a third language is another change to assess. Matching the approved translation checks implementation; linguistic approval still belongs to the designated reviewer.

If you include an extra, make the boundary visible

Sometimes including a modest addition is a sensible relationship decision. You can choose that deliberately after checking capacity. Specify the exact extra, whether the fee or date changes, and what would require another discussion.

A sentence such as “We can include this one additional headline revision in the current fee, with the Friday date unchanged” gives the client something definite. “We will take care of any final tweaks” leaves both parties guessing how much work remains.

For a retainer, use the same clarity around the available hours or agreed capacity: state which task moves when the new request takes priority. An existing monthly payment does not tell the team which of two competing tasks should happen first.

If you already started without approval, be candid about that. Explain what is complete and what remains, acknowledge that the change was not agreed, and discuss the remaining work before doing more. A surprise invoice is a poor substitute for the conversation you skipped.

For the Spanish-page example, your final message can now be straightforward:

Thanks. I have set out the Spanish addition in CR-01 for your approval.

The English launch stays on Friday. The additional Spanish page is $600,
with publication the following Wednesday by 12:00 UTC. That depends on
approved copy arriving Monday by 12:00 UTC and consolidated preview
feedback arriving Tuesday by 16:00 UTC. App localization is excluded.

Please confirm CR-01, including the fee, schedule and your responsibility
for Spanish-copy approval, through our agreed approval channel. We will
start the addition once that approval is recorded.