Calculate client savings from a hosted backend: an EGP worksheet

Define a case small enough to calculate

You need basic spreadsheet arithmetic and a list of the client's current tasks and bills. Our fictional company runs one preferences website: hosted login, per-user saved settings and owner notifications. It has no customer payments and no AI. Payment, withdrawal and AI charges are therefore outside this limited example, not zero-priced features of a wider proposal.

The existing frontend host stays. A separate backend host can be cancelled after migration. We assume a first Gammal Tech project and data within the advertised 1 MB per user per project. An additional project could introduce a one-time fee; confirm its current amount rather than inventing it. Use one currency throughout this worksheet.

Calculate provider usage before claiming a saving

The official integration guide, checked on 12 October 2026, lists 200 free OTP codes per month per project, then 0.40 EGP per code. Owner notifications cost 0.40 EGP each when delivered, with no free allowance. Login, logout, session checks and user JSON storage within the documented limit are free.

For this example, forecast 800 OTP codes and 150 delivered notifications per month. Count OTP codes, not users or website visits. The formulas are:

• OTP cost = max(monthly codes minus 200, 0) × 0.40.
• Notification cost = delivered emails × 0.40.
• Example OTP cost = (800 minus 200) × 0.40 = 240 EGP.
• Example notification cost = 150 × 0.40 = 60 EGP.
• Total forecast provider usage = 300 EGP per month.

The client funds its wallet and transfers money to the project balance. A wallet top-up alone is not the completed funding step. Refresh rates and expected volumes when preparing a real quote.

Build the monthly before-and-after table

Use a fictional labour value of 400 EGP per hour, a 600 EGP backend-host bill and a 200 EGP frontend-host bill. These are teaching inputs, not market averages or Gammal Tech prices. The two hours of work after migration cover integration and supplier review, rather than assuming backend-related work disappears.

In this invented baseline, the old workflow has no separate OTP or email bill. A real client may have one; add it rather than copying that zero. Ongoing frontend security and support remain in both columns. Provider review and recovery or exit planning belong inside the retained work estimate.

Explain what the 1,900 EGP difference means

The monthly economic improvement is 5,600 minus 3,700 = 1,900 EGP. It consists of four released hours valued at 1,600 EGP plus a 300 EGP cash-cost reduction. For fixed-salary staff, those four hours do not automatically reduce payroll. They may let the team finish another task or avoid additional work later.

If an outside contractor bills hourly and four hours truly disappear from the bill, that labour reduction can become cash savings. Record the actual contract before changing the label. Do not count the same four hours once as a cancelled invoice and again as extra productivity in the total.

A useful client sentence is: “Under these assumptions, this releases four hours a month and reduces non-labour bills by 300 EGP. The estimated combined value is 1,900 EGP.”

Include migration effort and use the right payback

Assume 14 migration hours at 400 EGP, plus a fictional 400 EGP one-time deployment expense. The hours cover mapping and vendor questions, implementation, testing, documentation and handover. Total economic migration cost is 14 × 400 + 400 = 6,000 EGP. This 400 EGP expense is an illustrative project cost, not a provider setup charge.

Economic payback is 6,000 ÷ 1,900 = about 3.2 months, assuming a steady full monthly benefit after completion. If salaried staff perform migration within existing paid time, incremental migration cash is 400 EGP and cash payback is 400 ÷ 300 = about 1.3 months. If migration labour is externally billed, cash outlay is 6,000 EGP; with fixed-salary ongoing staff, cash payback is 6,000 ÷ 300 = 20 months.

Keep these interpretations labelled. Cancellation notice periods, overlapping hosting and delayed adoption can postpone the first full benefit. Add them to an actual estimate.

Test the assumptions that can change the decision

In the high-usage case, OTP costs 640 EGP and notifications 400 EGP, so usage totals 1,040 EGP. Cash bills rise even though the assumed time benefit remains. Economic payback becomes 6,000 ÷ 1,160, about 5.2 months. If a scenario produces zero or negative monthly benefit, there is no positive simple payback under those assumptions.

Create and check your client worksheet

Replace the fictional rates with dated bills, task estimates and measured usage. Keep columns for quantity, rate, formula and who confirmed the input. Have the client mark costs that can actually be cancelled and identify which hours are salaried or externally billed.

Your deliverable is the monthly table, migration total, both benefit labels and at least two sensitivity cases. It passes review when another person can reproduce the arithmetic and explain why staff time is not automatically cash. The common mistake is comparing an old total containing maintenance against a new total containing only API usage.

Common questions

Are these guaranteed savings or Egyptian market prices?

No. Labour and hosting inputs are fictional. Use the documented provider rates with the client's own volumes, contracts and operating tasks.

Can I use this estimate for a payments website?

Only after adding current payment, withdrawal and any other applicable charges, plus the work required for trusted verification and fulfillment. This worked case contains no payments.