What you will learn
A successful handover gives the client control of the project and enough evidence to operate the agreed workflow. This lesson turns an integration into an ownership record, an acceptance checklist and a support runbook. You will distinguish frontend rollback from hosted-data recovery and set support boundaries without assuming shared accounts or undocumented access features.
Prepare the handover before the launch meeting
You need an agreed scope, the source files and a working integration you are authorized to demonstrate. Use fictional preferences for this lesson. The reference project contains login and per-user settings; any owner-notification step is optional and must have an approved budget. No payment or AI transaction is required for this exercise.
Prepare three deliverables: an ownership and configuration sheet, an acceptance record, and an operations guide. Fill them during implementation rather than reconstructing them at the end. A client should be able to find the current files, the responsible people and the next step during a problem without calling the original developer first.
Put the correct owner in control
Each person has their own verified Gammal Tech account. The client controls the account and project used for its application. The official guide also requires client payments, when enabled, to use the client's verified account and matching payout identity. Do not collect a client's sales through your own account.
Have the client enter private account details itself. If you guide settings during a meeting, explain each action and let the owner perform it. Do not ask for passwords, PINs or identity documents, and do not promise a delegated-access feature without documented support. Agree separately how future authorized configuration changes will be carried out.
| Item | Responsible role | Handover evidence |
|---|---|---|
| Gammal Tech account and project | Client owner | Owner can locate the project independently |
| Domain and hosting account | Client's authorized administrator | Renewal and access responsibility recorded |
| Frontend source and deployment | Named maintainer under agreement | Current version and deployment instructions |
| Usage budget and owner inbox | Client owner | Funding steps and review date |
| Business permissions and sensitive workflows | Named business and technical owners | Trusted decision points documented |
Record configuration without collecting secrets
Write the actual project ID into the configuration sheet and identify the file or setting that uses it. It is a public identifier. Session tokens are different: keep them out of screenshots, URLs, email and diagnostic notes. There is no Gammal Tech developer secret API key to invent or transfer.
List the exact HTTPS domains used by the application. The documented limit is four registered domains, and the bare domain and its www version count separately. Match the actual deployment, not an old development address. Include the SDK source, the frontend release identifier and the location of the integration code.
Describe the data shape and its limits. For example, language and topic preferences are user-editable fields; they cannot grant staff privileges or paid access. Record top-level merge behavior and nested-object replacement so a future maintainer does not overwrite part of a saved object unintentionally.
Agree what counts as a completed delivery
- Ownership: the client identifies its project and domains without using the developer's credentials.
- Login: the agreed button opens the hosted flow and the page reflects the resulting sign-in state.
- Data: a fictional preference survives retrieval and a later authorized sign-in for the same user.
- Separation: if two-user testing is in scope, two consenting people use their own accounts and fictional records; each sees the expected data.
- Failure: interrupted operations show a useful neutral message rather than a false success or sensitive diagnostic output.
- Handover: the owner locates the source, operating notes, usage assumptions and support route.
Record the date, release and observed outcome for each case. Do not manufacture extra personal accounts for testing. If a notification case would create a paid delivery, first obtain the agreed usage authorization; this lesson can use a labelled paper walkthrough instead. Acceptance of these cases is evidence of the agreed integration behavior, not a penetration-test certificate.
Write a runbook that starts with symptoms
Login does not open: check whether the user clicked the button, whether the browser blocked the popup and whether the current HTTPS domain matches the documented configuration. Escalate with the time, page address and a sanitized description. Never request the user's session token.
A preference appears missing: ask the user to check that they used their intended account. The maintainer checks the project configuration, whether retrieval completed and how empty data is displayed. Do not overwrite data repeatedly while investigating or ask for a full customer record by email.
An optional notification is missing: the owner checks the expected inbox and project balance. Funding means wallet top-up followed by transfer to the project. Distinguish request acceptance from confirmed delivery; do not add blind resend loops. The SDK already handles brief network retries.
The website may have been altered: stop ordinary troubleshooting through the suspect page. Use a trusted device and established contacts to secure publishing access, preserve relevant evidence and involve appropriate incident help. Hosted data does not make altered frontend code harmless.
Separate release rollback from data recovery
Keep a known release of the frontend and document how the authorized maintainer restores it. Practise the file rollback on an appropriate non-production copy. Restoring frontend files does not automatically restore per-user data held by the backend.
For hosted data, record the provider-confirmed recovery, retention, export and deletion arrangements required by the project, including unanswered questions. Do not invent a backup guarantee or a bulk-export tool. Define what the business can do while a service is unavailable and what evidence must be preserved before a migration or cleanup.
If payments are later included, expand the handover to cover trusted verification, ownership of order records, duplicate fulfillment and current transaction and withdrawal fees. Browser success messages and customer screenshots must not become the authority for delivery.
Set a support boundary the client can use
Write who receives a request, the agreed response hours, what evidence is useful and how work outside the original scope is quoted. Distinguish your maintenance responsibility from provider support. The published Gammal Tech support contact is support@gammal.tech; send a concise sanitized problem description, not credentials or identity documents.
Keep a dated list of open items and a next-review date for usage, frontend dependencies and provider changes. The NIST small-business guide includes response and recovery alongside protection, which explains why these operating notes belong in delivery rather than being postponed until an incident.
Rehearse the handover without your own intervention
Give a partner the three documents and a fictional incident: “A learner's saved topic is not visible.” Ask them to locate the owner, relevant acceptance case, first diagnostic steps and escalation route. They should find all four without guessing or requesting a token.
Your deliverable passes when ownership is clear, acceptance evidence is dated, costs have an owner and recovery unknowns are visible. The common mistake is treating a source-code ZIP as the entire handover. Files are necessary; operating knowledge and control of the project make them usable.
Common questions
Can I hand over my own Gammal Tech account to the client?
Plan the project under the client's own verified account instead. Do not transfer personal credentials or assume an undocumented account-transfer or delegation feature.
Does restoring my website files restore hosted user data?
No. Frontend rollback and hosted-data recovery are separate operations. Confirm the available data-recovery arrangements with the provider and record their limits.
Lesson references
Documentation checked on 12 October 2026. Recheck current documentation before implementing or quoting a client project.