What you will learn
Sell a clear business result: a working integration, fewer backend tasks to operate and a documented handover. This lesson helps you explain Gammal Tech to a prospective client, demonstrate a suitable workflow and write a reviewable proposal. Your deliverable is a one-page offer with acceptance criteria, ownership and the remaining security responsibilities.
Prepare before your first client conversation
You should already understand hosted login, per-user data and the difference between identifying a user and authorizing a business action. Read the Gammal Tech documentation and build a small preferences demonstration with fictional information. If account verification is still pending, prepare a clearly labelled paper walkthrough; do not present mock screens as a live integration.
Your service is the discovery, implementation, testing and maintenance work you perform. The client's application connects to Gammal Tech's hosted API; you are not installing the Gammal Tech platform on the client's server. A remaining server may still support trusted business logic or other integrations.
Use a problem-first conversation script
Start with a question: “Which part of your website creates repeated work today: signing people in, remembering their preferences, or managing a separate backend?” Listen for a specific task. Ask who owns it, how often it fails and what the failure costs in time. Do not announce a percentage saving before the client has described the baseline.
Then try this explanation: “I can assess whether hosted login and user data fit this workflow. If they do, I can integrate them and document the tasks you no longer operate locally. We will also list what stays with your team, including website publishing, staff accounts and business permissions.”
Close discovery with a check: “You need customers to remember their own preferences. You do not need a shared staff database in this phase. Is that accurate?” An explicit correction now prevents an expensive disagreement after delivery.
Give a five-minute demonstration with a visible boundary
- State the example. “This is fictional course-preference data, not a production customer record.”
- Show a signed-out page. Explain why login starts after a user action rather than forcing a popup on arrival.
- Sign in with your own authorized account. Keep account identity documents, session credentials and dashboard access out of the presentation.
- Save a harmless preference and retrieve it. Show the visible result, not tokens or raw diagnostic output.
- Explain the boundary. The preference is user-editable. It does not grant administrative powers or prove payment.
- Show the handover checklist. Point to ownership, expected behavior and support arrangements.
Do not demonstrate paid notifications or payments merely to make the meeting more impressive. Use a labelled illustration for optional paid features until the client has approved the scope and costs. A short, understood demonstration is stronger than several unexplained buttons.
Answer objections without expanding the promise
| Client question | Useful reply | Next evidence |
|---|---|---|
| Will we still need cybersecurity? | Yes. We can reduce selected backend work while keeping the remaining responsibilities explicit. | Before-and-after responsibility list |
| What if our website is hacked? | A database kept only elsewhere is absent locally, but malicious frontend code can still misuse data or sessions available to the page. | Frontend protection and incident plan |
| Can every user field control permissions? | No. User-editable values need a separate trusted authority for privileged decisions. | Permission design |
| How much will we save? | We will calculate removed costs, retained work, usage and migration effort. | Cost worksheet with assumptions |
OWASP's authorization guidance supports separating identity from permission decisions. Present that principle as application design guidance, not as an external certification of your work.
Package your work around concrete deliverables
Discovery package: deliver the current workflow map, suitability assessment, data inventory, responsibility list and estimate. Acceptance means the client can identify what moves, what stays and which questions remain unresolved. This can end with a recommendation not to migrate a particular workflow.
Implementation package: deliver the approved login and preferences flow, source files, configuration notes, fictional-data test evidence and an operating guide. Define the supported pages and devices in the proposal. New payments, staff roles or integrations require their own agreed scope.
Maintenance package: specify scheduled frontend and dependency review, integration checks, usage review and a support contact. State the response window you can actually provide. These are packages of your professional work, not invented Gammal Tech subscription plans or a promise of continuous security monitoring.
Quote your fee separately from hosting and provider usage. Before adding payments, review transaction and withdrawal charges separately; the example proposal below has no payments or AI.
Complete a small proposal before asking for approval
Example client: a fictional Egyptian training studio. Goal: returning learners remember their selected topic and display preference. Included: one HTTPS site, hosted login, per-user preferences, clear signed-out and error states, a handover session and source delivery. Excluded from this phase: payments, AI, shared staff records and authorization for paid courses.
Ownership: the client controls its own verified account and project; the developer supplies implementation files and instructions. The client enters private account information itself. No shared credentials or assumed delegation feature is part of the proposal.
Acceptance: the agreed sign-in, save, reload and sign-out cases pass with fictional data; the correct client project and HTTPS domains are documented; the client can locate support instructions. Commercial items to complete: your quoted fee, usage assumptions, implementation dates, response window and change-request process. Do not ask the client to approve blank commercial fields.
Signoff: ask the client to confirm the goal, inclusions, exclusions, responsibilities, costs and acceptance evidence together. Record unresolved requirements before either party authorizes implementation.
Rehearse, then check your deliverable
Ask a partner to play the client and interrupt you with two objections from the table. Give a two-minute explanation and a five-minute walkthrough. Afterwards, have the partner state what your service delivers and what remains the client's responsibility. Rewrite any sentence that made them think the whole company no longer needs security.
Your finished deliverable should contain the proposal, demonstration steps and a list of evidence supporting each claim. A common mistake is selling the removal of all security work when the real value is simpler operation of specific functions. The NIST small-business guide places supplier choices within broader risk management, which is a useful perspective for this conversation.
Common questions
Can I sell this work before becoming a cybersecurity expert?
You can offer work you can competently deliver and describe it accurately. API integration experience does not qualify you to promise penetration testing, incident response or complete security assurance.
Should I put every client project in my own account?
The client should control its own account and project. Do not share account credentials or collect a client's customer payments through your personal verified account.
Lesson references
Documentation checked on 12 October 2026. Recheck current documentation before implementing or quoting a client project.