Images are AI-generated illustrations, not documentary photographs or product screenshots.
Scope creep: describe the change without blaming the client
A request can grow because the buyer learned something useful, not because they intend to exploit you. Start by restating the new request and comparing it with the agreed scope. A different page, additional integration or new audience may change the project. Keep the conversation factual. “This adds a second language version” is more constructive than “you keep changing everything.” You can acknowledge the value of an idea without agreeing to absorb it silently.
Distinguish corrections from additional work
Fixing a defect against an agreed requirement is different from implementing a new preference or feature. Review the brief, approved version and acceptance criteria before labelling a request as scope creep. If your original scope was vague, acknowledge that rather than treating every clarification as an upsell. Clear boundaries are more credible when you also take responsibility for delivering what was promised. Keep a record of the reasoning, not only the invoice change.
Assess the full impact
Estimate design, implementation, testing, documentation and approval effort. Consider whether the request affects earlier completed work. An apparently small feature can introduce new security, accessibility or maintenance obligations. Do not quote instantly when you need to inspect a dependency. Explain the uncertainty and when you can return with options. Upwork’s pricing comparison notes that fixed-price changes may require renegotiation; an hourly contract also needs budget and priority monitoring.
Offer choices rather than an ultimatum
Possible responses include replacing a lower-priority deliverable, extending the schedule, increasing the budget or placing the request in a later phase. Show how each choice affects the outcome. Avoid invented urgency or language designed to embarrass the client into paying. If a request cannot be delivered responsibly with the available resources, say so. A useful choice makes the constraint understandable instead of hiding it inside a vague promise.
Document approval before implementation
Record the agreed change, revised deliverables, cost, timing and dependencies. Update milestones or time caps through the platform’s supported process where relevant. Do not assume a casual reaction emoji authorizes a substantial expense. Confirm the person approving the change has the necessary authority. If no option is approved, continue with the original agreement unless the change makes that impossible, in which case explain the issue and pause the affected work.
Improve the next project brief
After delivery, review which requests were predictable and which resulted from genuinely new information. Add clearer examples, exclusions or review checkpoints to future scopes. You might specify the number of templates rather than merely the number of pages. Do not respond by making contracts hostile or refusing every useful adjustment. The goal is a change process that protects quality and trust. A documented boundary is usually easier to discuss than accumulated resentment after unbilled work.
Sources and further reading
Upwork: fixed-price and hourly project trade-offs