Rebuilding a package-forwarding business on a modern platform

The business

Many US stores won't ship to the Gulf or the Horn of Africa, and the ones that do charge heavily for it. eShip4ME gives each customer a personal US suite address. Orders arrive at the warehouse, get combined into a single shipment, and travel onward to Saudi Arabia, the rest of the GCC, and Somalia.

The business had been running on an older ASP.NET MVC system. It worked, but it was hard to change, and it couldn't support what the company wanted next: a mobile app, a CRM, referrals, and a shared account with its sister marketplace.

What we built

• A marketing site and customer portal in English, Arabic and Somali, with a full right-to-left layout for Arabic.
• An operations portal for the warehouse: receiving and photographing packages, consolidating them into outbound boxes, printing labels, and creating shipments.
• Live carrier rating from Aramex and FedEx, so operators can check margins against the customer price list.
• Wallet and invoice billing, a referral program, a CRM, customer support, and reporting.
• A Flutter mobile app for iOS and Android that shares its core with the sister marketplace's app.

Architecture decisions

The backend is a .NET 10 modular monolith with eleven modules, including identity, customers, warehouse, shipping, billing, CRM and referrals. Each module owns its own database, and modules react to each other through events: when someone signs up, the customer profile and suite number are created in the background rather than in the sign-up request itself.

Sign-in runs through a dedicated identity service that issues signed tokens, shared with the sister marketplace, so one account works across both brands. On Azure, the API and identity service run as containers released by exact image version, secrets live in Key Vault, and deployments authenticate without stored passwords.

A migration designed for no surprises

Moving a live business is riskier than building a new one. Customers have packages sitting in the warehouse, money in their wallets, and suite numbers printed on orders already in transit. So the migration tooling was designed around a few rules:

• Customers keep their suite numbers, and existing passwords keep working.
• The import never triggers notifications, so loading thousands of records can't email thousands of customers.
• Every run can be repeated safely: records are matched to their legacy source, so a second run updates rather than duplicates.
• No row disappears silently; every rejected record is logged with a reason.
• Wallet balances must reconcile to the cent, and a failed reconciliation blocks the cutover.
• Only the personal data the new platform needs is carried over.

A migration is finished when the money reconciles, not when the import completes.

Where it stands

The new platform is live at eship4me.com with carrier rating, and moving existing customers off the legacy system is planned in phases: discovery, dry-run imports that change nothing, then a short switchover window. Online payments go live alongside it.