_hamza eldemery

#situation

YallaEdara sells PMP certification training in Arabic and English. When I took it on, the platform was already partly live and every enrollment was manual: students paid by bank transfer, filled in a Google Form, and an administrator added them to a course by hand. The codebase I inherited had broken payments, an unreliable quiz module, page components running past two thousand lines, a single unclustered PM2 process, and link prefetching on every anchor.

#constraint

The old .NET platform had to keep serving students while the new one was built. That ruled out a one-shot cutover: the data migration had to be re-runnable, and it had to preserve every reference, because students' certificates and exam history are the product. The legacy database was also inconsistent — some video lectures had several URLs recorded against them — so parts of the schema's intended meaning had to be recovered by reading the original source code rather than trusting the data.

#what i built

A closed enrollment loop that removes the administrator from the path entirely: checkout through Stripe or Paymob, webhook-driven enrollment, automatic grading, and automatic certificate issue with QR validation.

Around it: an incremental, re-runnable migration for users, courses and certification records; a finance review module built to the client's tax workflow, with period-based payment and invoice navigation and mark-as-checked / mark-as-taxed state; and production hardening — PM2 clustered across three instances, a right-sized server, Sentry, and an OpenAPI codegen pipeline covering 36 services and 495 models to stop backend and frontend types drifting apart.

I also chased down a 429 rate-limit failure that appeared only for the platform's most engaged students. It was invisible on a normal account, so I built a high-volume test profile — many courses, certificates and exams — reproduced it, traced the redundant calls across the dashboard, and rebuilt the surface into grouped, tab-loaded queries. That work also removed the empty-dashboard state those users were hitting.

#result

$86,000 processed in the first four months under the new system, with no human touchpoints. 11,000 users, peaking around 1,800 concurrent. The finance review module is in daily use by the client's finance team, and they have roadmapped government-API automation on top of it.

#situation

Flawtrack brought me in to unblock a frontend team that had stalled on Talepex, a multivendor marketplace built on Saleor. The admin panel was half-finished, and the vendor panel — the surface sellers actually live in — did not exist.

#constraint

The backend returns product data across several non-atomic GraphQL queries. A seller editing a product can therefore have a refetch land mid-edit and overwrite what they have typed. From the seller's point of view that is data loss, not a rendering quirk, and it had to be solved in the client rather than by changing a backend the rest of the team depended on.

#what i built

The vendor panel from scratch — product, order and warehouse management — and I finished the admin panel. I owned the product module end to end: the data shape, the seller-facing add-and-edit flow, and a client-side state layer that reconciles those multi-query updates without discarding in-progress edits on refetch.

For performance I restructured queries, introduced code-splitting, and moved heavy filtering off the request path into precomputed aggregates on the backend. Separately, I replaced the ad-hoc per-screen implementations with a reusable React component system now used across more than forty screens.

I am the main frontend reference for a product team of four — one backend, two fullstack, one frontend — and I introduced code review standards, story-point estimation and a feature planning workflow. I mentor the in-house frontend developer on performance, patterns and review practice.

#result

Admin panel page load and time to interactive down by roughly 40%. Both panels are in daily use by the operations team and by sellers. The public storefront is linked above; the admin and vendor panels are internal and are described here rather than shown.

#situation

Medexsepeti is a multivendor marketplace in the dental-supply niche, originally built as a monolithic EJS application. The business did not just want a faster site: it wanted to sell the marketplace itself as a product to other operators. That turns a rewrite into a different problem. A single-tenant codebase with a dental-supply catalogue hardcoded through it cannot be resold, no matter how well it performs.

#constraint

The site was live and ranking. Any migration that lost SEO would have cost the business its acquisition channel, so the rewrite had to hold search performance while the rendering model changed underneath it. And the multi-tenancy could not be a later refactor — branding, catalogue shape, and seller flows had to be tenant-configurable from the start, or the second tenant would fork the codebase instead of configuring it.

#what i built

I led the frontend build of the React and Next.js admin and vendor portals from scratch, owning the logic flow, architecture and feature implementation as the platform scaled.

I drove Lighthouse from 32 to 85 over a few weeks: refactoring expensive logic, cutting library chunk size, redrawing the server/client component boundary, splitting above-the-fold APIs from below-the-fold, optimising SVGs, migrating images to WebP, and repairing accumulated SEO regressions.

With a backend engineer I co-designed the product variant system end to end — the backend data shape, the seller-facing UX for adding variant pairs, and a consumer-facing flow that lazily loads variant availability on selection instead of loading the full matrix upfront. A variant model that assumes one industry is the fastest way to block the next tenant, so it had to describe dental supplies and anything else equally well.

Then I proved it. I stood up CarSpace, a white-label car marketplace on the same platform for a car-selling merchant, with its own branding, single-item carts and installment payments.

#result

Three weeks from start to a working second marketplace in an unrelated industry — the test of whether the multi-tenancy was real rather than aspirational. The platform is now sold as a product under the MDX Cart name.

Along the way: Lighthouse 32 to 85, and growth to 15,000 active users, over 150 sellers and more than 10,000 products, all running on the variant system.

The link above is the live CarSpace tenant, which is the part of this work that is publicly visible. Medexsepeti's own storefront at medexcart.ae is no longer online, and the admin and vendor portals are operator-facing and cannot be shown.

Throughout, I mentored the in-house frontend developer with structured 1:1s, tracked learning focuses and notable-mistake review cycles.

#situation

A Gulf-region client needed a school discovery platform: parents searching for schools across six countries, in Arabic and English, with content that changes by country.

#constraint

Country scoping and language direction are not the same axis. A parent in Saudi Arabia reading English and a parent in the UAE reading Arabic need different content and different layout mirroring, and both need pages a search engine can index per country. Getting that wrong produces either duplicate-content penalties or the wrong schools shown to the wrong parents.

#what i built

The entire front end, solo, on Next.js 15 App Router with React Server Components: country-scoped routing and content swaps across six Gulf countries, full Arabic RTL and English LTR mirroring, Elasticsearch-backed advanced search, a blog system, and SEO-optimised school pages. Tailwind and Radix UI for the interface layer.

#result

Live at mdares.ai, serving six countries in two languages from a single codebase, built and shipped by one engineer.

#situation

Layla is a multi-tenant SaaS LMS currently in build. It generalises what I learned shipping YallaEdara: the same course, enrollment, assessment and certification machinery, but tenant-isolated and sold to many training organisations rather than built for one.

#constraint

Multi-tenancy has to be enforced at the data layer, not in the UI. Every query is tenant-scoped, and a role check that leaks across tenants is a security incident rather than a bug. That single constraint shapes the schema, the RBAC design and the mobile client equally.

#what i built

In progress: a five-tier learning hierarchy, RBAC across six roles, payments, and Flutter mobile parity with the web client. AI adaptive learning is on the roadmap and is not yet built.

#result

Not yet shipped. It is listed here because it shows current direction, and the figures above are design targets rather than measured results. I am happy to walk through the schema and the tenancy model on request.