Price website integration changes before they become hidden projects

Start from the accepted baseline

Keep the last accepted scope and release available when a client asks for a change. Identify whether the request corrects something that failed the agreement, adjusts an existing behavior or introduces a new outcome. Those are different commercial conversations even when the same developer edits the page.

Do not make the client describe the technical solution. Ask what problem they want solved and how they will recognize success. Then compare that outcome with the baseline. A clear distinction between defect correction and added scope protects both parties: the provider can charge for genuine new work, while the client is not asked to pay again for an agreed result that was never delivered.

Review the impact in five directions

Do the review before choosing the price band. A wording change may touch only one page; an apparently small “view all learners” button changes data access and authority. Put uncertainty in the worksheet instead of hiding it inside a large unexplained contingency. The client can then decide whether to investigate, simplify or proceed.

Work through three fictional requests from Alexandria

An Alexandria training provider has an accepted member website with personal learning preferences. The first request changes a help-button label. You estimate half an hour for the edit, half an hour for focused review and half an hour for release coordination. A fictional fixed quote of 900 EGP covers that stated work and scope. It is a professional-service example, not a platform charge.

The second request remembers a display preference. You estimate six hours for the data rule, interface, compatibility checks and release, at an illustrative selling rate of 450 EGP per hour, plus 300 EGP of direct project testing cost. The proposed fee is 3,000 EGP. Hosting and usage are reviewed separately.

The third request lets instructors view every learner and approve completion. Do not price it as another preference field. Offer a bounded architecture investigation before an implementation commitment.

Recognize the changes that alter the trust boundary

The Gammal Tech storage contract supplies per-user application JSON with top-level merging and replacement of supplied nested objects. Adding a field inside an existing nested object therefore needs a compatibility review so the update does not unintentionally replace other values.

The shared instructor request raises a different question. User-editable personal data does not provide a trusted administrator role or a global staff roster. OWASP’s authorization guidance supports enforcing permission decisions in a trusted place. Identify the required authority and shared-data architecture before promising the feature.

For any new paid-service flow, include trusted confirmation and fulfillment design in its own scope. A browser success screen or an editable paid flag is not sufficient evidence. These checks identify the real work early rather than turning a useful client idea into a difficult launch surprise.

Write a short change order the owner can approve

The change order should name the request, business reason, affected baseline, included work, excluded work, assumptions, acceptance cases, fee, payment milestones and expected release window. Identify the owner who can approve it and the point at which the new commitment begins.

For the display preference, acceptance might state that the user can choose one of two options, the preference survives a supported new session and existing lesson progress remains unchanged. Also specify a sensible default for older records. That is more useful than “add settings support.” If the request requires discovery first, price that deliverable separately and explain that its result may change the implementation options. Agreement should happen before the team performs the additional work.

Include release and reversal thinking in the price

A completed change includes more than an edited screen. Update the relevant acceptance checks, owner instructions and component register. Decide whether existing records need adaptation and how the team will recognize an unsuccessful release.

For website code, document a return to a known version through the hosting and deployment process you actually control. For changed data, describe the supported recovery or correction process separately; do not assume a code rollback reverses every data write. Gammal Tech’s published services are the capability reference, not evidence of an undocumented rollback API.

Keep the owner informed about any release dependency, such as account action or an approved domain configuration. A predictable small release is part of the value of a professional integration service.

Use completed changes to improve future estimates

Close the change order with actual effort, acceptance, release date and any remaining follow-up. Compare estimate and actual work by cause: unclear requirement, unfamiliar component, missed dependency or a later client decision. This helps you improve your own process without treating every difference as someone else’s fault.

Your reusable deliverable is the five-direction worksheet plus a signed decision record. Review several completed requests together before changing your standard prices. If the same small addition repeatedly becomes a large task, adjust the underlying component or the initial discovery question. Good change control keeps improvements welcome while making cost and responsibility visible before the work starts.

Common questions

Should every small request require a long contract document?

No. Use a proportionate written record, sometimes a short approved change order. It should still identify the outcome, scope, fee, acceptance and person approving the work.

Can I use the monthly care allowance for a change?

Yes, when the change fits the agreed allowance and scope. A new permission model, shared workflow or major feature may require a separate investigation or project.