Overview

A customer-facing iOS app for anyone who owns a car and wants to keep it maintained. It stores each car's maintenance history and invoices, maps a full network of relevant garages, surfaces offers, and handles booking and payments end to end. It grew to 5,000+ users.

My role

I owned the entire app end to end — architecture, UI/UX and every feature in Swift & SwiftUI — talking to a backend built in ASP.NET by the backend team.

What I built

• Maintenance history & saved invoices — every service and receipt kept per car.
• Garage network — browse and search a full network of relevant garages.
• Offers feed — promotions and discounts surfaced to users.
• Payment flow via Moyasar, with OAuth2 auth and login.
• Push notifications, deep linking and a referral flow.
• Image upload/download and in-app PDF generation.
• Profile, settings and full Arabic/English localization.
• Analytics and session tracking with AppsFlyer and Smartlook.
• Prototyped an internal AI assistant with car context (not shipped).

Highlights

I designed and shipped the whole app in 2021–2022, before AI coding tools existed. Adding deep linking and push notifications was a major piece of work that meant refactoring and reworking the app end to end.

Status

First shipped in 2022; maintained and updated through 2026.

Screens

Overview

An iPadOS point-of-sale app for car-service stores. The cashier rings up services, builds the cart and issues the invoice — all from a single, always-visible screen built for speed and reliability at the counter.

My role

A v1 already existed; I came in and built v2 — restructuring it for cleaner code, a new design, faster launch and load times, and a better UI/UX with new features. Another developer later joined on smaller features; I led the team and managed the GitHub repo.

What I built

• Rebuilt the app end to end for v2 — architecture, design and performance.
• Cart and checkout for day-to-day car-service sales.
• Invoice creation and receipts from a single screen.
• Receipt printing via Epson printers (integrated with a teammate).
• Faster launch and load times, and a refreshed UI/UX over v1.

Highlights

The hardest part was keeping the whole flow on one screen. Building an invoice and cart is a long, multi-step process, so I designed it to stay on a single page the entire time — the cashier never loses context mid-sale.

Status

Built in about three months and shipped in 2025; in production use.

Overview

Jamaatna (جمعتنا) is an all-in-one platform to run weddings and events from the invite to the door — elegant digital invitations, one-tap RSVP, QR entry codes and a live attendance dashboard. Fully bilingual Arabic & English (RTL).

My role

This is my own startup. I do everything — product design, frontend, backend, localization, business and marketing.

What I built

• Elegant digital invitations with one-tap RSVP.
• QR entry codes and a scanner check-in flow.
• Live attendance dashboard that updates in real time.
• Guest-list and seating management.
• Multiple event types with a host dashboard.
• Payments, analytics and automated reminders.
• Full Arabic/English (RTL) localization.

Highlights

The check-in is the flashy part: scan a guest's QR at the door and the live attendance dashboard updates in real time — no refresh, everyone watching sees the count move.

Status

Live — launched in 2026.

Screens

Overview

An Airbnb-style marketplace for booking event venues in Riyadh — map search, categories (halls, chalets, farms, majlis), ratings, favorites and bookings. Arabic-first with English.

My role

A freelance build for Howamesh — I built both the frontend and backend on Replit. It's an MVP.

What I built

• Map-based search with venue categories (halls, chalets, farms, majlis).
• Venue detail pages with photos, ratings and reviews.
• Booking flow, favorites and a host listing flow.
• Admin and payments.
• Arabic-first UI with English.

Highlights

Map search over Mapbox with an Arabic-first, RTL layout — browsing venues on the map the way locals actually search.

Status

Built in 2026 as an MVP.

Overview

A Next.js & TypeScript dashboard for a car-services business, used by owners and garages. I supported the wider dashboard and built the invoicing system inside it — ZATCA Phase 2 tax invoices (simplified & A4), quotations and reporting.

My role

I owned the invoicing system's UI and UX inside the dashboard. The rest of the dashboard — reporting, analytics, customer management, inventory and staff — I supported.

What I built

• Invoicing UI/UX for simplified and A4 tax invoices.
• ZATCA Phase 2 compliant tax invoices.
• Quotations flowing into invoices.
• Supported the wider dashboard: reporting, analytics, customers, inventory and staff.

Highlights

The invoicing had to be ZATCA Phase 2 compliant — the Saudi e-invoicing standard — rendering correct simplified and A4 tax invoices that owners and garages rely on daily.

Status

Built in 2025; in use through 2026. Private company project.

Overview

A bilingual (Arabic & English, RTL) marketing site for a car-service center in Saudi Arabia — maintenance, inspection and detailing services, a services gallery, customer reviews and one-tap WhatsApp contact.

My role

A freelance client project — I designed and built the whole thing from scratch.

What I built

• Bilingual Arabic/English with full RTL.
• Services sections, a gallery and customer reviews.
• One-tap WhatsApp contact.
• SEO work and custom-domain setup.
• Built from scratch in vanilla HTML/CSS/JS on GitHub Pages.

Highlights

Built from scratch with no framework — just vanilla HTML, CSS and JS — fully bilingual with RTL and one-tap WhatsApp deep-linking, plus SEO and a custom domain.

Status

Shipped in 2025.

Screens

Overview

A bilingual (Arabic & English, RTL) personal-brand portfolio for Salih Bawarith — a Riyadh-based F&B operations manager, specialty-coffee expert and Arabic calligrapher. The site frames his career as a coffee “roast curve”: a scroll-drawn profile with braided lanes for the several roles he ran at once, alongside galleries of his calligraphy and his work & events.

My role

I designed and developed the whole site — the “roast-curve” concept, the bilingual RTL layout and the galleries. All content lives in one JavaScript data file, so Salih can update his timeline, photos and calligraphy without touching HTML.

What I built

• A “roast-curve” career timeline — a scroll-drawn profile with braided lanes for concurrent roles.
• Fully bilingual Arabic/English with a language toggle and complete RTL mirroring.
• A calligraphy gallery and a work & events album gallery — grid + lightbox, with on-demand image and video loading.
• Category filters and “show more” pagination so the galleries scale.
• A data-driven architecture — all content in one JS file, so it updates without editing HTML.
• Built from scratch in vanilla HTML/CSS/JS with no build step, plus SEO and a custom domain on GitHub Pages.

UX decisions

• Framing the career as a “roast curve” instead of a bullet list — you read momentum rising over time, not just dates.
• Braided lanes so concurrent roles are legible at a glance rather than flattened into one column.
• Galleries load images and video posters on demand, with “show more” paging, so a large archive stays fast on mobile.
• Every screenshot and photo opens in a full-screen lightbox you can swipe through.
• Keyboard- and screen-reader-accessible (focus management, Escape to close, ARIA labels), with all motion gated behind prefers-reduced-motion.

Analytics

Umami (privacy-friendly and cookieless) with a custom tracking layer I wrote: named events for every click and for scroll depth, plus a visibility “heartbeat” that sends periodic pageviews so a single-page site still reports real visit duration. Every call is guarded, so a blocked or slow tracker never breaks the page.

Highlights

The idea I like most is the “roast curve” — reading a career like a coffee roast profile, with time along the bottom and momentum rising, and braided lanes showing the roles that overlapped. It turns a plain CV into a story, in two languages, with zero framework or build step.

Status

Shipped in 2026, live at salihbawarith.com.

Screens

Overview

A Raycast extension that puts daily gold prices one keystroke away. It shows live prices per gram for the 24K, 22K, 21K and 18K karats commonly quoted in Gulf markets, the daily change versus the previous close, and 1, 3, 6 and 12-month averages from real daily closes — all in the currency of your choice.

My role

My own project — I designed and built the whole extension in TypeScript on the Raycast API, and submitted it to the official Raycast store.

What I built

• Live spot prices per gram for 24K, 22K, 21K and 18K.
• Daily price change versus the previous close.
• Period averages — 1, 3, 6 and 12 months — from real daily closes.
• Karat selector to switch which karat's averages are shown.
• Selectable display currency: SAR, AED, KWD, QAR, BHD, OMR, USD, EUR, GBP.
• Quota-friendly caching to stay within the free metals.dev API tier.

Highlights

The interesting constraint was the free API tier — only 100 requests a month — so I built quota-friendly caching that serves fresh prices and month-long averages without ever blowing the budget.

Status

Source is public on GitHub and it's submitted to the Raycast store — pull request #29634 is in review.

Screens

Overview

Turathiyat (تراثيات) is a Riyadh dealer in rare banknotes, coins, stamps and heritage antiques whose whole business lived inside a classifieds marketplace. I built them a catalogue site on a domain they own: Astro renders roughly 130 Arabic, right-to-left pages — 119 pieces and 315 photos — shipping about 1.3 KB of client JavaScript. Every buy button opens WhatsApp with a prefilled Arabic message carrying that piece’s permanent reference code, so a lead can be traced back to the page that produced it. The catalogue has since moved off a committed JSON file into a Postgres table read per request, behind a phone-first owner panel — so the shop can be edited from a phone instead of through a rebuild — and a one-tap sync pulls the marketplace’s current inventory into a review queue the owner clears before anything reaches the live site, with sold pieces flipped automatically so a live buy button can never ship on stock that’s gone.

My role

I built all of it end to end — the scraper and data pipeline, the site, the content architecture, the SEO and GEO work, the analytics, the owner panel and its marketplace-sync review queue, and the deployment. Refreshing the catalogue is no longer a rebuild: a stepper pulls the marketplace a page at a time, proposes every change, and the owner applies or dismisses each one from a phone.

What I built

• A Node scraper over the marketplace’s GraphQL API that fetches listings and photos and normalises them into one dataset.
• An Astro static site: a homepage, catalogue, six category pages, a collector’s guide, FAQ, shipping and about pages, plus a page per piece — all prerendered.
• A dataset that is the union of everything ever scraped, so a sold piece keeps its page, its URL and its accumulated rankings instead of vanishing.
• Frozen reference codes (TRH-0001 and up) assigned once per piece and never reassigned, because they end up in real WhatsApp conversations.
• Client-side Arabic search over a prebuilt JSON index, ranking available stock first, with no-result queries recorded as demand the inventory does not cover.
• Build-time image work with Sharp: social cards and search thumbnails generated per listing, skipping whatever already exists so rebuilds stay cheap.
• Deployed on Netlify with a custom domain, a build-time config module holding every deployment-specific value, and a first-party analytics proxy at the edge.
• A phone-first owner panel on the site itself: sign in, edit a piece, add one, mark one sold, and freeze any field the sync should stop proposing changes to.
• A one-tap sync with the marketplace that pulls its current inventory, diffs it against the catalogue, and queues every difference for the owner to approve or dismiss — nothing reaches the live site unreviewed, except a sold-state flip, which applies automatically so a live buy button can never ship on stock that’s gone.

SEO & GEO

• Product and Offer JSON-LD on all 119 listing pages, with real prices where they exist and a sold-out state on sold stock.
• ItemList on the catalogue and category pages, FAQPage on the homepage and FAQ page, BreadcrumbList everywhere, and a Store node linking to the seller’s identity-verified marketplace profile — which is what ties a brand-new domain to an established reputation.
• Titles written to differ deliberately from the marketplace’s, so the new pages are not fighting a far stronger domain over identical text.
• Arabic URL slugs carrying the listing id as a stable prefix, so a seller editing a title can never break a URL — lowercased, because the host redirects mixed-case paths and a canonical must not point at a redirect.
• A robots.txt that allows AI crawlers by name — GPTBot, ClaudeBot, PerplexityBot, Google-Extended and others — rather than relying on a wildcard the opt-out gates ignore.
• An llms.txt serving a plain-text inventory and reference summary, and a generated sitemap, so assistants can read the catalogue without rendering it.
• A collector’s guide and FAQ written to answer what buyers actually ask — currency history, how to read a grading slab, telling originals from copies — so the site earns visits that no single listing could.

UX decisions

• Arabic-first and RTL by default — not an English site translated, but a site whose native direction is right-to-left.
• A reply-speed promise stated up front, and a floating WhatsApp button that follows the reader on every page, because on mobile the buy action should never be more than a thumb away.
• Sold pieces stay browsable and honest: the page survives, the state flips, and the buy button does not ship on stock that is gone.
• Every photo is the real item, shot as-is, with a note saying so — the trust signal that matters most in a market full of copies.
• Descriptions derived from the seller’s own words with the price line, sign-off and keyword-stuffing removed; no invented rarity or provenance claims, since these are real goods sold to real buyers.

Analytics

Microsoft Clarity is live for session recordings and heatmaps — the qualitative half. The quantitative half is a PostHog event layer I wired through a first-party proxy on the site’s own domain, so a tracker blocker sees only same-origin traffic; it stays silent until the project key is set, and it no-ops safely without one. Its events are built around a placement property, so the useful question — which surface actually converts, the item page, a category, the guide, or the floating button — is answerable rather than guessed at.

Highlights

The part I like most is the attribution: a WhatsApp message arriving with TRH-0102 in it came from this site, and one without it did not. It needs nothing installed on the seller’s side, and it turns “is the site working?” into a question with an answer. The honest limit is that WhatsApp lets a sender edit the prefilled text, which is why the click is also recorded independently — two records to reconcile, not one to trust.

Status

Shipped in 2026, live at turathiyat.net.

Screens

Overview

Marwah Stories Library (مكتبة القصص) collects the illustrated children’s books of Marwah Alhalabi, who writes them as page-scheduled scripts — a table of page number, story text and scene description, and nothing else. No illustrations, no book. I built everything between that file and a book a child can leaf through: a locked illustration style profile, AI-generated artwork produced against it, Python tooling that turns the delivered sheets into individual pages, and a dependency-free right-to-left flip-book library. Two books are live — 64 pages of artwork — with a print-ready PDF built per story.

My role

All of it: the illustration direction and the style system, the prompt work, the page tooling, the reader site and the deployment. The author supplies the script — the rest of the path to a finished book is mine.

What I built

• A style profile — one JSON file that locks the series look (chibi proportions, no black outlines, soft cel shading, warm subjects on cool backgrounds, a radial backlight) and carries prompt templates for Midjourney, Flux and Gemini. It separates style from subject on purpose, so a new story inherits the look without inheriting the last book’s cast.
• Artwork generated with AI against that profile, page by page, from the scene descriptions in the script. The consistency rules in the profile are what stop a character drifting between pages — and between books.
• A Python slicer that cuts a finished contact sheet into page images. The sheets are AI-generated, so the grid is genuinely irregular — column widths differ from row to row — and dividing the sheet evenly slices through artwork. It detects gutters from the image in three passes, and recomputes columns inside each row band to catch the odd bottom row.
• A dependency-free static library: a shelf of story cards, and a page-flip reader on a pinned copy of StPageFlip, navigable by keyboard, buttons and drag-to-turn.
• One shared page renderer behind both the reader and a headless print harness, so a story whose captions are drawn over the artwork at read time exports to PDF with its words intact instead of silently shipping wordless pages.
• A repeated diagonal watermark carrying the author’s name across every page, in the reader and the exported PDF alike, because the books circulate before they are published.
• Deployed as static files on Netlify — HTML, CSS and plain ES5 JavaScript, no build step, no runtime dependencies.

Making it read like an Arabic book

• StPageFlip only turns pages the Western way: it lifts the right-hand page and swings it leftwards, spine on the left. An Arabic book does the opposite.
• Mirroring it in CSS is the obvious fix and the wrong one — it reverses the Arabic captions baked into the artwork and desynchronises the library’s pointer maths from what the reader actually sees.
• So the page list is handed to the library backwards. Reading a reversed book from its last page to its first is physically the same motion as reading an Arabic book front to back: the spine lands on the right, the cover opens leftwards, the earlier page of a spread sits on the right where an Arabic reader looks first, and corner-dragging still works natively because none of the library’s geometry was touched.
• The cost is two page numbers in play at once, so they are never mixed: moving forward in the story calls the library’s “previous”, and the number shown to the reader is carried on the page object rather than inferred from the library’s index.
• A blank leaf goes in front of the closing page rather than behind the cover, so the story stays paired as (1,2), (3,4) — odd page on the right — and the spare leaf ends up at the back, like a printed book’s end paper.

UX decisions

• The shelf is the landing page: cover, title, author, one line of summary, and chips for category, age range and page count — enough to choose a book without opening one.
• Captions exist in two forms and both are supported: burned into the artwork, or drawn over the page at read time. The second keeps the words selectable and lets a typo be fixed without regenerating a picture.
• A story with no artwork yet stays on the shelf marked “coming soon” instead of disappearing, so the library reads as a series that is growing.
• Arabic-first throughout — interface, fonts and direction. There is no English mode, because the readers are children reading Arabic.
• No framework and no bundler; the catalogue is a plain script rather than JSON fetched at runtime, so the site also works opened straight from disk.

Highlights

What I like most is that the whole thing collapses into a repeatable pipeline. A new story arrives as a script table, and every step after that is either a documented command or a prompt template resolved against the style profile — so the third book costs a fraction of the first and still looks like it belongs beside it. The honest limit is the artwork: AI generation still needs a human eye on every page, and the slicer’s grid detection assumes panels sitting on a white sheet.

Status

Shipped in 2026 with two books live and more in production. The repository is private — it holds the author’s unpublished work.

Screens

Overview

Howamesh is a Saudi creative collective — a network of designers and builders working on brand identity, strategy, products and content. They had a brand deck and no website. I built them one: a bilingual landing page that presents the collective’s principles, the fields it works in, an archive of 39 delivered works, and a contact form. It is a static site with no framework and no runtime dependencies, and both languages are real pages rather than one page translated by JavaScript.

My role

I built all of it — the content pipeline, the build, the design system, the typography work, the animation and the deployment. The only thing I did not make is the brand itself: the palette, the illustrations and the wordmark are the collective’s own, and the page is a transcription of their deck rather than a reinvention of it.

What I built

• A build script that renders one template function twice and writes two complete pages: Arabic at the root, canonical and right-to-left, English under /en/, each carrying the other’s hreflang alternate.
• Two content modules, one per language, that are the single source of the copy — plus a check script that fails the build if a work, a client or a section is missing from either edition, so the two can never drift apart.
• The nine working principles as a selectable network diagram: pick a node and the matching principle and its illustration cross-fade in.
• An archive of the collective’s 39 works, grouped by field into native disclosure elements, so a long index stays short until someone actually wants it.
• A contact form on Netlify Forms with a honeypot, pending, error and success states, and a native POST fallback when JavaScript is unavailable.
• Light and dark themes sharing one set of semantic tokens: the system preference by default, with a manual choice that persists.
• Generated sitemap and robots files, canonical and hreflang tags, Organization structured data and social cards, all produced by the same build.
• Deployed on Netlify at a custom domain, with security headers, a content security policy that allows no external origin at all, and a cache policy separating fingerprinted assets from the ones that change.

Typography & fonts

• The two house typefaces are self-hosted and subsetted, so the page makes no third-party request and the font policy can be locked to the site’s own origin.
• Each family is cut twice, Latin and Arabic, declared under one family name with non-overlapping Unicode ranges — which is what keeps a hundred kilobytes of Arabic outlines off the English page.
• Only the display subset for the page’s own script is preloaded: self-hosting without a preload is slower than a font CDN, because nothing discovers the font until the stylesheet parses.
• Arabic body copy is set one weight heavier than the Latin, because the display face loses its thin joins and its dots at the lighter weight in a way the Latin does not.
• The hero wordmark is the real vector artwork from the brand deck, inlined into the HTML so it paints with the first frame. It uses swash forms the default font instance will not reproduce, so it stays artwork rather than live type.

UX decisions

• The language toggle is a plain link between two real URLs, so switching language works with JavaScript off and both editions are indexable.
• Every directional rule in the stylesheet is written with logical properties rather than left and right, so the mirrored edition is correct by construction instead of by a pile of overrides.
• The script is optional by construction: reveal animations are gated behind a class only JavaScript can add, so with the script blocked every section is simply visible.
• The brand mark turns as you scroll, driven by a CSS scroll timeline rather than a scroll listener — so scrolling back up unwinds it exactly, and nothing runs on the main thread per frame.
• Rotation is not mirrored for the right-to-left edition. A turn is not a logical property, and mirroring it would make the two pages disagree about which way scrolling down turns the mark.
• All motion is switched off under a reduced-motion preference, including the card hover lift.

Highlights

The lesson I keep from this one is about Arabic web fonts. The standard subsetting tool drops the contextual shaping features by default, and Arabic then renders as a row of disconnected isolated letters — while the file size looks exactly right and every automated check passes. A correct byte count proves nothing about the shaper; the only way to know is to render Arabic and look at it. The build script now carries that warning in its header, because it is the kind of failure that is invisible to anyone who does not read the script.

Status

Shipped in 2026, live at howamesh.co.

Screens