Not just finished screens.Decisions that made the product useful.

Context

The consumer experience needed to support iOS and Android while the app, dashboard, and website were developed in parallel within a 16-week engagement.

Decision

We built a single Flutter codebase targeting iOS and Android, with full Arabic RTL and English support.

One shared mobile codebase kept the two platform experiences aligned while the dashboard, website, and backend were being built in parallel.

Context

A financial UI can be built LTR and later mirrored and translated, or designed right-to-left from the start. For a team moving off paper day-books, the accounting language on screen had to match how they already worked.

Decision

We designed RTL from the first screen, with Arabic accounting terminology and mirrored data tables, then reused that MUI-based design system across the platform.

The staff issuing invoices and keeping journals work in Arabic; an interface that reads like their existing paper workflow made adoption and training far smoother than a retrofitted translation would.

Context

A donation form that only asks for a number makes the donor guess what their money does, and leaves the charity describing impact in copy that nothing in the system backs up.

Decision

We gave every project a unit of impact stored on the record — one food pack, one furnished wooden house — with the preset amounts derived from that unit, and showed percent funded and the amount still needed alongside it.

It turns an abstract ask into something closer to a purchase, and because the unit and the goal are data rather than marketing text, the progress bar, the suggested amounts, and the impact line can never drift apart.

Context

A customer app, a technician app, an admin dashboard, and a marketing site could each have been scoped as its own project with its own backend slice. The pricing, status, and permission rules would then have been written four times.

Decision

We built one Laravel API over one MySQL schema as the system of record, and made every surface a client of it — including the website, which reads live services and pricing from the same endpoints the app uses.

An order is touched by a customer, a technician, and an admin within the same hour. One authoritative model means a status change, a price, or a permission is defined once, and a new surface is a new client rather than a new source of truth.

Context

Arabic support could have been bolted on after the English site was finished, which typically produces broken RTL layouts and awkward typography.

Decision

We designed both language experiences together from day one: RTL-mirrored grids, locale-aware routing via next-intl, and dedicated Arabic typography (Cairo alongside Poppins).

For a UAE family audience, Arabic is a primary experience, not an afterthought. The testimonial confirms the payoff: the RTL build was flawless on the first pass.

Context

A bilingual-ready build would have meant designing left-to-right and mirroring afterwards. For a product whose entire audience reads Arabic, that only imports layout bugs the audience is the first to hit.

Decision

I built the site as Arabic-only from the document down — the page ships as `lang=ar` and `dir=rtl`, with every layout, icon direction, and form flow authored right-to-left.

Nothing has to be mirrored under pressure later, and the details that usually break in retrofitted RTL — input alignment, carousel direction, breadcrumb order — were simply never wrong in the first place.

Context

Candidates at different stages prepare very differently, and a single flat offer would not match a first-timer's needs against a final-round candidate's.

Decision

We mapped the candidate journey and packaged it into four tracks, Fundamentals, Intermediate, Advanced, and Fitment (behavioral), priced per interaction.

Each stage of prep gets a package that matches it, so the offer stays relevant from the first case rep to final-round fitment.

Context

A three-part service like this could be presented as a feature list, but for investors buying an outsourced pipeline, trust is the real barrier.

Decision

We built a proof-led page architecture that explains the service model, expected workflow, available evidence, and the steps between interest and a strategy call.

Specific proof and a visible process make the offer easier to evaluate than a generic list of capabilities.

Context

The firm offers strategy, technology, operational support, and learning services, each with several specialist offers.

Decision

We grouped the catalogue under Consulting, Technology, Outsourcing, and Institute, with direct access to the underlying services.

The grouping makes a broad offer scannable while preserving a short route for visitors who already know what they need.