Anas Rezk.

Problem

Tourlane’s main customer-facing app had outgrown Create React App. Cold builds and CI pipelines were slow, local dev startup lagged, and Webpack’s HMR had grown unpredictable on a codebase of this size — every change cost the team seconds of waiting that added up across dozens of engineers, many times a day.

Options weighed

I evaluated three realistic paths: stay on CRA and tune Webpack (lowest risk, lowest ceiling); migrate to Next.js (powerful, but a heavier architectural shift than the app needed and a larger blast radius); or adopt Vite (esbuild-powered dev server, Rollup production builds, minimal config). I prototyped the Vite path against the real app to validate the build output and dev experience before committing.

Tradeoff

Vite meant trading CRA’s batteries-included familiarity for an explicit, configure-it-yourself setup — plugins, env handling, and a handful of CRA-specific assumptions to unwind. The bet was that a one-time migration cost would pay back continuously in faster builds and a sharper feedback loop, without forcing the broader framework change a Next.js move would have required.

Outcome

Build times dropped by roughly 50% and local dev startup became near-instant, visibly tightening the feedback loop for the whole frontend team. The migration shipped incrementally with no disruption to feature delivery, and the leaner config lowered the day-to-day cost of working in the codebase.

Problem

Dinex is a point-of-sale platform intended to serve many independent businesses from one codebase. Each tenant needs isolated data and branding, the floor-facing app has to reflect orders and inventory in real time, and the whole system needs authentication and authorization that hold up across tenant boundaries — without standing up and maintaining separate deployments per customer.

Options weighed

For tenant isolation I weighed a shared schema with row-level scoping against domain-based separation, and chose domain-based routing so each tenant resolves to its own context cleanly at the edge. For the stack, I paired Next.js for the customer- and admin-facing surfaces with Angular for the operational POS client, letting each side play to its strengths. For live updates I compared polling against a persistent connection and went with WebSockets for genuinely real-time order and inventory state.

Tradeoff

Running two frameworks raises the integration and consistency cost — shared types, design tokens, and auth have to be deliberately unified rather than assumed. Domain-based separation adds routing and provisioning complexity up front in exchange for clean isolation and a simpler mental model per tenant as the platform grows.

Outcome

The architecture is proving out as an ongoing side project: domain-based tenant separation, real-time sync, and a shared auth layer are in place, and the platform is structured to onboard new tenants without per-customer forks. It’s my most complete architectural ownership work — spanning multiple frameworks, tenant isolation strategy, and a real-time system designed to scale without per-customer forks.

On the mobile side, I built the POS app in React Native and Expo — including a native receipt-printer integration that renders Arabic text as images to work around the Epson SDK’s encoding limitations.

Problem

Tourlane’s frontend had grown into multiple applications, each reinventing buttons, inputs, and layout primitives in slightly different ways. The drift showed up as inconsistent UI for customers and duplicated effort for engineers, with no shared source of truth for components or design decisions.

Options weighed

The choices were to keep copying patterns between apps (cheap now, expensive forever), adopt a third-party UI kit (fast, but a poor fit for Tourlane’s brand and bespoke flows), or build an in-house design system tailored to the product. I went with an owned system: React components in TypeScript, styled with CSS-in-JS for co-located theming, and documented in Storybook as living, testable documentation.

Tradeoff

An in-house system is a real ongoing investment — it needs versioning, an adoption path, and an owner who fields requests and guards consistency. The payoff is a single source of truth that fits the product exactly and removes the per-app reinvention tax, which justified the maintenance commitment.

Outcome

The design system became the shared UI foundation across 5+ applications, giving customers a consistent experience and giving engineers a documented, reusable toolkit instead of one-off components. Owning it end to end — API design, accessibility, docs, and rollout — made it a backbone of the frontend org rather than just another package.