Systems designed,
deployed, and
measured in ms

A payment gateway for the Saudi market, integrated with Moyasar. School owners sign up as merchants, and guardians pay their children's tuition fees online with whatever they carry: Visa, Mastercard, mada, American Express, Apple Pay or Google Pay. It is the kind of system where "it works" is not the bar. Every path a payment can take, including the ones where the network drops halfway, has to end with the money and the records agreeing.

6

Ways to pay on one checkout: Visa, Mastercard, mada, Amex, Apple Pay, Google Pay

Live

In production, taking real fees from real guardians

AR / EN

Arabic-first and right-to-left, with an English switch

Screens

1. 1 / 1

   

What I built

1. 01

   Moyasar, integrated end to end

   Card payments with 3-D Secure, mada for the local debit network, and wallet payments, all through Moyasar. Each payment carries the invoice it settles in its metadata, so any charge can be traced back to one school, one guardian and one fee without guesswork.

2. 02

   Apple Pay and Google Pay, done properly

   Domain verification, merchant validation and wallet buttons that only appear on devices that can actually use them. On a phone, a guardian settles a term's fees with Face ID in a couple of seconds, with no card number to type.

3. 03

   The redirect is never the source of truth

   A customer returning from the payment page proves nothing. The status is fetched from Moyasar on the server with the secret key, and the amount and currency are checked against the invoice before anything is marked paid. A tampered callback URL cannot mark a fee as settled.

4. 04

   Webhooks and redirects that race each other

   The webhook and the customer's redirect can arrive in either order, twice, or not at all. Status changes are idempotent and keyed on the payment ID, so whichever arrives first does the work and the rest are harmless. If neither arrives, reconciliation still catches the payment.

5. 05

   The edge cases that cost real money

   Double-clicks and resubmitted forms that must not charge twice. 3-D Secure challenges that are abandoned halfway. A connection lost after the card was charged but before the page came back. Amounts handled in halalas, never floats. Partial refunds, and declines explained in plain Arabic rather than a raw gateway code.

6. 06

   Many schools, many families, kept separate

   Each school is its own merchant with its own fees, invoices and payment history, and a guardian with several children pays each child's fees from one account. Tenancy is enforced where the data is read, not just hidden in the interface.

Visit the landing page (opens in a new tab) The landing page is public. The merchant and guardian system behind the login is private.

The public storefront for an international fashion brand, built in Nuxt. It sells across fifteen storefronts in six languages from one codebase, runs campaign-specific versions of its homepage and collection pages, and has to hold a design-led brand to the pixel — all without letting a large catalogue, heavy imagery and a dense set of commercial rules slow it down.

34

Market and language variants served from one codebase

6

Languages, each with its own SEO signals

15

Storefronts, including separate .au and .jp domains

Screens

1. 1 / 1

   

What I built

1. 01

   Performance under a real catalogue

   The challenge was never a lightweight page — it was thousands of product images, variant logic, promotions, stock rules and market-specific pricing, all on the critical path of a shopper who will leave if it stalls. The work was keeping the rendering path short and the payload disciplined while every one of those conditions stayed in play.

2. 02

   Thirty-four locales, one codebase

   Six languages across fifteen storefronts, routed by market rather than duplicated per market. Currency, pricing, availability and copy resolve per locale, and the separate Australian and Japanese domains hang off the same build rather than being forks of it.

3. 03

   Pixel-exact to a design-led brand

   Happy Socks is a brand people buy for how it looks, so the tolerance between the design file and the shipped page was zero. Type, spacing, colour and motion were built to match rather than approximated, and that fidelity had to survive every locale, where the same layout carries text of very different lengths.

4. 04

   A homepage that exists in several versions

   Campaigns like the one in the screenshot replace the hero, the messaging and the featured rails. The page is composed from swappable sections rather than rebuilt per campaign, so marketing can run several versions without a code change for each one.

5. 05

   Collection pages that stay fast under filters

   Category and collection surfaces carry the heaviest load — large grids, filtering, variant imagery — and they are also the pages search sends people to. They were built to render usefully on the server and stay responsive as a shopper narrows the set.

6. 06

   Full SEO, multiplied by every market

   Every locale variant declares hreflang for the others plus an x-default, with canonicals and metadata resolved per market — a multilingual store gets this wrong far more often than it gets it right. Structured data, crawlable server-rendered markup and clean URL routing per storefront complete the picture.

Visit happysocks.com (opens in a new tab) Live and public — go and click around.

A single-page launch site for a mixed-use commercial development in West Cairo — administrative, medical and retail units. Arabic and right-to-left as the primary direction rather than a mirrored afterthought, with the whole page shaped around one job: turn a visitor into a qualified enquiry.

Sold out

The development sold through in full

95 / 100

PageSpeed performance, mobile

CLS 0

No layout shift at all

Screens

1. 1 / 5

   

2. 2 / 5

   

3. 3 / 5

   

4. 4 / 5

   

5. 5 / 5

   

What I built

1. 01

   Right-to-left first, not mirrored later

   Arabic is the primary direction here, so the layout was built in logical properties from the start. Numerals, prices, the currency suffix and the Latin brand names all sit correctly inside RTL text, which is the part that usually breaks when a left-to-right design is flipped at the end.

2. 02

   The shortest possible path to an enquiry

   The form sits in the hero beside the pitch, WhatsApp is offered next to it for anyone who would rather not fill anything in, and every unit card carries its own button. Nobody has to hunt for how to get in touch, and nobody has to scroll back up to do it.

3. 03

   A form that asks for almost nothing

   Name, mobile, and an optional interest — three fields, one of them optional. The anti-spam check only appears once someone starts typing, so a genuine visitor never waits on a challenge before they have shown intent.

4. 04

   Sold units left on the page

   Rather than removing what has gone, sold units stay listed with the price struck through and a sold badge. It answers "is this moving?" without a single line of persuasion, and it makes the remaining availability credible.

5. 05

   Fast enough that speed never cost a lead

   Reserved space for every image, transitions on transform and opacity only so animation stays off the main thread, and a critical path kept short. The result is in the Proof section above: 95 performance, 100 accessibility, 100 best practices, 100 SEO, and a Cumulative Layout Shift of exactly zero.

6. 06

   The outcome

   Enquiry volume rose and the development sold out. A landing page cannot sell a building on its own, but it can stop losing the people who were already interested — which is what this one was built to do.

Visit the live page (opens in a new tab) Live and public — go and click around.

A travel catalogue site for a tour operator, built in Next.js and TypeScript. Content nests several levels deep — regions hold destinations, destinations hold packages — and each package carries its own gallery, pricing, day-by-day itinerary, hotels and cruise options.

Screens

1. 1 / 1

   

What I built

1. 01

   A catalogue three levels deep

   Regions contain destinations, destinations contain packages. Every level is its own browsable surface with its own routing and metadata, so a visitor can enter at any depth from search and still land somewhere coherent.

2. 02

   Packages with everything attached

   Each package carries an image gallery, pricing, a day-by-day itinerary, the hotels involved and any cruise legs — assembled from separate sources into one page that still has to load quickly and read clearly.

3. 03

   An animated map of the route

   The path a package travels is drawn out on a map rather than listed, so the shape of the trip is obvious before reading a single itinerary line.

4. 04

   Find an agent, on the map

   A geographic agent finder, so a visitor can go from browsing a package to a named human near them without dropping into a contact form first.

5. 05

   The surrounding commerce surfaces

   Experiences and tours per destination, cruises, special offers, downloadable brochures and a request-a-quote flow — each one a distinct template sharing the same component layer.

6. 06

   SEO at 100%, on-page and off-page

   Both sides audited and tracked in SEMrush. On-page that meant per-template metadata and structured data, canonical handling for content reachable through more than one route, and internal linking that keeps a catalogue this deep fully crawlable — alongside the off-page work on the same scorecard.

7. 07

   Next.js used for what it is good at

   Rendering chosen per route rather than globally, typed data contracts end to end, and images, fonts and metadata handled by the framework so the catalogue stays fast as it grows.

Visit the live site (opens in a new tab) Live and public — go and click around.

A flight search and booking engine built on Sabre GDS for a tourism company. It runs as one Angular application embedded by iframe into several separate portals, each sharing the same booking surface with full two-way data communication back to its host.

Screens

1. 1 / 5

   

2. 2 / 5

   

3. 3 / 5

   

4. 4 / 5

   

5. 5 / 5

   

What I built

1. 01

   No UI packages — the components are mine

   Nothing in this interface came from a component library. The date-range calendar, the airport picker, the traveller stepper, the filter rail and the itinerary cards were all written for this product, which kept the bundle small and left no third-party upgrade path to be blocked by.

2. 02

   A from/to calendar built from scratch

   Two months in view, one continuous range selection across them, keyboard operable, and aware of the constraints a booking flow imposes — a return that cannot precede a departure, and disabled days that still read correctly to assistive tech.

3. 03

   An airport picker that actually searches

   Matching on city, country, airport name and IATA code at once, so "new york", "JFK" and "Kennedy" all reach the same result. Debounced against the keystroke rate rather than firing a request per character.

4. 04

   One shared portal, not a copy per system

   Rather than reimplementing Sabre search inside every portal, I built it once and embedded it. Each host system communicates with the same surface in both directions, so a fix or a fare-rule change ships to all of them at once instead of being merged four times.

5. 05

   Hundreds of itineraries, filtered without re-querying

   A single flight search returns hundreds of itineraries — multiple segments, fare rules, airline combinations — and users expect to filter and sort all of it instantly. The full result set is fetched once into a normalised store, and the visible list is derived through memoised selectors as a pure transformation of raw results, active filters and sort order. Nothing mutates the source data, so components stay in sync and filtering feels instant without re-querying an expensive API.

6. 06

   Tuned for the volume Sabre returns

   Debounced inputs and throttled scroll handlers to keep the main thread free, signals for fine-grained reactivity instead of broad change detection, lazy-loaded routes and panels, and infinite scroll so a result set of hundreds of itineraries renders progressively rather than all at once.

The system itself is client-owned, so these screens are as far as it can be shown. Ask me for a walkthrough

My own system for clinics with several branches. Patients book online and hold the slot with a small deposit. The front desk and back office run the day from their own portal, and doctors and the owner work from a third one, with a chart for each specialty and the finances of every branch. It is three Angular applications in one Nx monorepo, in Arabic and English, light and dark. It runs entirely in the browser on a seeded clinic — three branches, eleven doctors and thousands of appointments around today's date — so a clinic can try every role before anything is connected to its own backend.

3 portals

Patients, front desk, and doctors with the owner, all on one shared domain library

5 charts

Dental, aesthetics, nutrition, pediatrics and lab, each loaded only when it is opened

AR / EN

Arabic and English, light and dark, with right-to-left built in rather than mirrored

Screens

1. 1 / 5

   

2. 2 / 5

   

3. 3 / 5

   

4. 4 / 5

   

5. 5 / 5

   

What I built

1. 01

   Three apps, one domain library

   Booking, manager and doctor are separate Angular apps, so each portal ships only what its users need. Slots, deposits, cancellations, payroll, profit and loss, and role-based permissions are written once in a shared domain library, next to a UI library and a theme library. A rule changed there changes in every portal. A GitHub Actions workflow builds all three and deploys them under one domain on every push.

2. 02

   A booking flow made for the phone

   Branch, specialty, doctor, then a day and a time. A ring on each day shows how much of it is still open, and the visit summary stays beside the slots. Reserving holds the slot and asks for a small deposit by InstaPay or Vodafone Cash, with the receipt uploaded on the spot. A hold that is never paid expires on its own, so nobody blocks a slot by changing their mind.

3. 03

   The front desk's day on one board

   Arriving, checked in, in session, done and no-show, with each patient a card carrying a live timer. Deposit receipts sit beside their bookings and are approved or rejected in one tap, with keyboard shortcuts for a busy morning. The day's numbers, from waiting time to expected revenue, move with the cards.

4. 04

   Cancellation as one policy

   What a patient may change or cancel online, and what happens to the deposit, comes from a single policy module that the booking site, the front desk and the doctor's schedule all read. When a slot frees up, the desk offers it to that day's waiting list on WhatsApp. Notifying never reserves anything, so the first person to book gets it.

5. 05

   A chart per specialty, loaded only when opened

   A 3D odontogram for dentists, an injection map with signed consent for aesthetics, meal plans and weight against target for nutrition, growth curves and vaccines for pediatrics, and a results desk for the lab. Each specialty is a deferred view with its own translations, so a dentist's browser never downloads the lab. Prescriptions warn about allergies and carry a QR code that a pharmacist can verify on a public page.

6. 06

   Every branch's numbers, every morning

   The owner sees revenue, expenses, no-show rate and profit across all branches or for one, with payroll and petty cash behind them. A short summary goes out on WhatsApp at 8 AM, before the first patient arrives.

7. 07

   Bilingual and themed from the first screen

   Arabic and English, with right-to-left handled in the layout rather than patched per page, and light and dark themes driven by design tokens. The charts are plain SVG components rather than a charting library, so they follow the theme tokens with nothing extra to load.

It runs in the browser on sample data, so I can take you through every role live: patient, front desk, doctor and owner. Ask me for a walkthrough