The hidden engineering costs of launching an e-commerce business in Egypt

Ask for an e-commerce quote and most of the conversation will orbit the visible parts: homepage, product page, cart, checkout, account page, maybe a dashboard. That is understandable. Screens are easy to imagine and easy to compare.

The problem is that the screen is not the expensive part of the business. The expensive part is all the state that starts moving once real customers arrive: payment attempts, failed payments, settlement files, courier statuses, product variants, returned orders, coupon mistakes, abandoned carts, ad tracking, inventory updates, support tickets and finance questions.

That is why two stores that look similar can have completely different engineering costs. One is a catalogue with checkout. The other is an operating system for commerce.

If you are still asking what the initial build should cost, start with what software development actually costs in Egypt. This article is the second conversation: what the quote often leaves outside the frame.

The quote is usually for launch, not operation

Most e-commerce proposals are build-to-launch proposals. They answer one question: what will it cost to get a store live?

That is not the same as: what will it cost to run the store without losing orders, confusing customers or making finance rebuild the truth in spreadsheets every week?

The difference matters because launch hides work. A demo checkout can succeed once. A real checkout has to handle duplicate clicks, expired payment sessions, customers who close the bank OTP page, webhook delays, gateway downtime, out-of-stock items, partial refunds, coupon abuse and delivery failures.

The cheapest quote often assumes all of that will be handled manually. That can be fine for the first month. It is dangerous when the business starts to work.

Payments: the fee is only the visible cost

Founders compare gateways by transaction fee because the number is easy to see. In Egypt, the public rates for card payment providers often sit close enough that the fee is rarely the whole decision. The real engineering cost is everything around the transaction.

You need to budget for:

• Gateway integration. Hosted checkout, iframe, mobile SDK and direct API integrations have different PCI, UX and engineering implications.
• Webhooks. Your system should trust server-to-server payment confirmation, not only the browser redirect after checkout.
• Failed and pending payments. A customer can be charged while your order is still marked unpaid if webhook handling is weak.
• Refunds. Full refunds, partial refunds, cancelled orders and returned orders need clear state in both your system and the gateway.
• Reconciliation. Finance needs to match orders, gateway fees, settlements, refunds and bank deposits.
• Support visibility. Customer service needs to answer "was I charged?" without asking an engineer to inspect logs.

The mistake is treating payment as a button. Payment is a workflow.

If you want the gateway comparison itself, I wrote that separately in Payment gateways in Egypt: Kashier vs Paymob vs Fawry vs Fawaterak vs Geidea. Here the point is simpler: whichever gateway you choose, the hidden cost is making your own system behave correctly when payment is messy.

Shipping is an integration, not a phone call

Many early stores start with manual shipping: export orders, send them to a courier, update customers by hand. That works until order volume grows or customers start asking where their package is.

Shipping becomes engineering work when you need the store to know what happened after checkout:

• address validation and governorate coverage;
• shipping price rules by city, weight, basket value or courier;
• courier order creation;
• airway bill or label generation;
• delivery status sync;
• failed delivery handling;
• return pickup requests;
• cash-on-delivery reconciliation, if you support it.

The hidden cost is not only the API integration. It is the state model. An order is not simply "paid" or "shipped." It can be packed, handed to courier, out for delivery, delivery failed, rescheduled, returned, refunded or partially refunded.

If the admin panel cannot represent those states, the team will create a parallel operating system in spreadsheets. That spreadsheet will become the real store, and the website will become decoration.

Catalogue work is where small mistakes become daily labour

Product pages look simple from the outside. Inside the business, catalogue management is usually where the team loses hours.

The cost depends on the shape of what you sell:

• Simple catalogue: one product, one price, few images.
• Variant catalogue: sizes, colours, SKUs, stock per variant.
• Fast-moving catalogue: prices and stock change constantly.
• Bilingual catalogue: Arabic and English names, descriptions, slugs and SEO metadata.
• Imported catalogue: data comes from Excel, ERP, supplier feeds or old systems.

Every additional catalogue rule creates admin work. Can an item have two sale prices? Can one colour be out of stock while another is available? Do product images belong to the parent product or the variant? Does Arabic copy need its own URL? Can the team bulk edit prices before Ramadan or Black Friday without breaking the site?

None of those questions are exotic. They are normal e-commerce. They are also why a serious store costs more than a set of product cards.

Promotions are small features with expensive edge cases

"We just need coupons" is one of the most expensive sentences in e-commerce scoping.

Coupons are easy if there is only one rule: take 10% off the basket. They become complicated as soon as the business asks normal marketing questions:

• first order only;
• one use per customer;
• free shipping above a threshold;
• buy two, get one free;
• exclude sale items;
• cap the discount amount;
• apply only to selected categories;
• combine or do not combine with another campaign;
• expire at midnight without timezone drama.

The danger is not that promotions are impossible. The danger is that a weak promotions engine can lose real money quickly. One wrong coupon rule during a campaign can cost more than building the feature properly.

For early stores, I usually prefer boring rules that are easy to explain, easy to test and easy for support to understand. Marketing may want cleverness. Operations needs predictability.

Analytics is not "add the pixel"

Egyptian e-commerce depends heavily on paid acquisition: Meta, TikTok, Google, influencers, affiliates, WhatsApp campaigns. That makes analytics part of the revenue system, not a decorative dashboard.

The hidden engineering cost is that tracking has to survive modern checkout reality:

• users jump between browser, bank OTP screens and payment pages;
• payment confirmation may happen through a webhook after the customer leaves;
• ad blockers and browser privacy features reduce client-side tracking;
• refunds and cancellations mean revenue is not equal to gross checkout attempts;
• duplicated events can make campaigns look better than they are.

For a serious store, the question is not "is the pixel installed?" The question is whether product views, add-to-cart events, checkout starts, purchases, refunds and order values are being recorded consistently enough that marketing can make decisions.

Sometimes the answer is client-side tags. Sometimes it is server-side events. Usually it is a staged path: start simple, then tighten tracking once the store has enough volume for attribution mistakes to matter.

Admin tooling decides whether the team needs the developer every day

The customer-facing site gets attention because it sells. The admin panel quietly determines whether the business can operate.

A useful admin surface should let non-engineers handle normal work:

• search orders by phone, email, order ID and gateway reference;
• update order state with an audit trail;
• see payment attempts and refund status;
• export orders for finance, courier or operations;
• edit stock and prices safely;
• manage roles so support, operations and finance do not all share one admin password;
• leave notes on orders that other team members can understand later.

Bad admin tooling does not always break launch. It breaks the months after launch. Every missing button becomes a support request. Every support request becomes developer time. Every manual database edit becomes risk.

This is where cheap e-commerce builds become expensive retainers.

Infrastructure is boring until the campaign works

Many stores are quiet most days and then suddenly receive a traffic spike from an ad, influencer, sale or seasonal campaign. That pattern matters because average traffic is not what breaks you. Peaks break you.

The basic engineering budget should cover:

• production hosting sized for realistic traffic;
• image optimisation and caching;
• backups and restore testing;
• uptime monitoring;
• error tracking;
• logs that can explain failed checkouts;
• a staging environment for plugin updates and campaign changes;
• basic security hardening.

You do not need to over-engineer day one. But you do need to know what happens when the store slows down during the one hour the campaign is working.

If the infrastructure decision itself is still open, read managed services vs. running it yourself. If the bill already looks wrong, use the AWS cost audit guide.

The practical budget table

These are not quotes. They are planning ranges for the work that often sits outside the headline build number.

The exact number depends on stack. Shopify or WooCommerce can reduce some of these costs because they come with plugins and admin screens. A custom platform can increase them because you own more of the machinery. But even on off-the-shelf platforms, the operational work does not disappear. It becomes configuration, plugin selection, glue code, testing and maintenance.

What to ask before signing

Before you approve an e-commerce quote, ask these questions in writing:

1. What happens if payment succeeds but the customer never returns to the website?
2. Can the system handle the same payment webhook twice without duplicating the order?
3. How will finance reconcile orders, fees, refunds and settlements?
4. Who creates shipping orders, and how does delivery status return to the store?
5. Can support search by customer phone and payment reference?
6. How are refunds, partial refunds and returns represented?
7. Can the team bulk import and update products without developer help?
8. Which promotions are included, and which ones are explicitly excluded?
9. Which analytics events are tracked, and where is purchase value confirmed?
10. Is there staging, backup, monitoring and a post-launch maintenance agreement?

If the answer to most of these is "we can add that later," translate it honestly: later has a budget.