Full-Stack · 2025 — Present · Still run by me today.
AZParts — Web + WhatsApp Auto Parts Marketplace
Saudi marketplace where scrapyards compete on your part request — two complete flows, web and WhatsApp, with payments, delivery workflows, and AI support.
- Scrapyards competing
- 399+
- Vehicles in network
- 131K+
- Channels
- Web + WhatsApp
- Payments
- EdfaPay · Tamara

Case study
The story
AZParts is a production marketplace for used auto parts in Saudi Arabia. Instead of a buyer calling scrapyards one by one, the platform broadcasts the request and lets specialized scrapyards compete on price. The customer journey runs as two complete flows: a full web marketplace, and a WhatsApp flow where a stateful bot handles search, premium sourcing requests, payment links, order status, and AI-assisted support. AZParts hired me to build it, then hired me again to run it — I’m still the one keeping it running today.
The problem
Finding a used part in Saudi means calling dozens of scrapyards, negotiating blind, and hoping the part shows up. Dealers, meanwhile, have inventory but no digital channel their customers actually use.
The build
A bidding marketplace with two complete flows — a full web experience, and the channel everyone already uses, WhatsApp. Buyers describe their car and part once; the system routes the request to matching scrapyards, collects competing offers, takes payment (one-time or installments), and manages delivery — with an AI support layer answering questions from a knowledge base.
What it changed
- Scrapyards bid on each request, so buyers get the lowest real price instead of negotiating alone.
- Two complete journeys — search, offers, checkout, delivery updates — one on the web, one entirely inside WhatsApp.
- Premium paid-search requests, refunds, and delivery assignment run on auditable, queue-backed workflows.
My part
- Own the platform end to end as product engineer: web app, WhatsApp flows, payments, and deployment.
- Built resilient webhook processing with signature validation, idempotency, and dead-letter capture for every provider.
- Designed the asynchronous inbound queue (Redis + BullMQ workers) that keeps WhatsApp conversations fast under load.
- Integrated EdfaPay (one-time) and Tamara (installments) with webhook reconciliation and refund workflows.
- Shipped the retrieval-augmented AI support flow (OpenAI + pgvector) with runtime-configurable limits.
What it does
- Guided vehicle search (make / model / year) with competing offers from scrapyards
- Stateful WhatsApp bot: part search, premium requests, checkout links, order tracking, human escalation
- Premium paid-search lifecycle: intake, service fee, status updates, refunds, notifications
- Delivery request APIs with driver assignment workflow
- AI support chat grounded in platform knowledge (RAG)
- Audit logging with export, and health checks across Redis/PostgreSQL
Hard parts
- Keeping conversational state coherent across a channel users treat as free-form chat.
- Reconciling payment provider webhooks reliably enough to run refunds without manual cleanup.
- Serving an Arabic-first audience with flows that still work for non-Arabic speakers.
Stack
Next.js (App Router) · Node.js · PostgreSQL + pgvector · Prisma · Redis + BullMQ · Twilio WhatsApp API · EdfaPay · Tamara payments · OpenAI (RAG support) · Docker + Caddy
Screens
Want the same arrangement, built and then run by the person who built it?
Tell me what yours runs on and what an hour of downtime costs you.