Mihbaj is Ijjad's own SaaS for independent cafes and restaurants: QR table ordering, separate cashier, kitchen and waiter workspaces, app-free loyalty, and reporting priced from the venue's own costs. It is live, so every claim here is checkable.

What is Mihbaj, and what did Ijjad build?
Mihbaj is a multi-tenant ordering and growth platform for independent cafes and restaurants that Ijjad designed, built, and runs as its own product. Guests order from a QR code on the table or a shared link, in Arabic or English, with no app to install. The order lands in separate cashier, kitchen, and waiter workspaces, and every paid order builds a customer record the venue owns.
- Ijjad's own product, not a client handover — live and open to inspection.
- Multi-tenant: one deployment, many venues, isolated data per venue.
- Five role-separated workspaces: owner, manager, cashier, kitchen, waiter.
- Orders re-priced server-side before acceptance, so stale prices cannot be ordered.
- Arabic and English as first-class layouts across guest and staff screens.
Check this one yourself
Most agency case studies ask you to believe a summary of something you cannot see. This one is a running product. Open it, switch it to Arabic, read the published terms, look at the product screenshots.
mihbaj.com ↗Every agency portfolio has the same problem. The best work is under NDA, the checkable work is small, and the client is rarely willing to let you publish what actually happened. Our answer was to stop waiting for permission and build a product of our own — one where nothing is hidden, because there is no client to protect.
The problem Mihbaj solves
An independent cafe that takes orders through a delivery app is renting its own customers. A cut of every order leaves before it reaches the kitchen, and the phone number, the order history, and the relationship stay with the app. The venue built the demand and pays rent on it indefinitely.
The obvious fix — a QR menu — solves the wrong half. A digital menu shows food. It does not take the order, route it to the kitchen, tell the waiter which table is waiting, or leave the venue with a customer record afterwards. The gap between “a menu on a phone” and “a working service loop” is where the actual engineering lives, and it is most of the product.
What we built
One deployment, many venues
Mihbaj is multi-tenant. One codebase and one deployment serve every venue, with isolated data and per-venue configuration for menus, branding, table sets, offers, and staff. That is a very different design from building one restaurant one website, and it is the constraint that shapes everything else: schema decisions have to hold for venues that do not exist yet, and a migration has to be safe for all of them at once.
Five roles, five workspaces
Owner, manager, cashier, kitchen, and waiter each get their own screen rather than one interface with buttons hidden by permission checks. A cashier sees open bills and kitchen timing. The kitchen sees what to prepare next. The waiter completes the service handoff. The owner can mark an item sold out from a phone and the guest-facing page reflects it immediately.
Building it this way costs more up front and is the reason it works during a busy service. A single screen with role-gated buttons is faster to ship and quietly awful to use when the room is full.
Prices are re-checked on the server
Every order is re-quoted before it is accepted. If a price changed, an item sold out, or an offer window closed between the moment the guest loaded the menu and the moment they hit send, the server catches it. The obvious version of this feature trusts the price the browser sends, which means a stale tab or a modified request can order at yesterday's price. For a venue running scheduled offers, that is the difference between a promotion and a leak.
Arabic and English, both first-class
Guest ordering, staff workspaces, and the marketing site all run in Arabic and English, with right-to-left treated as a real layout direction rather than a mirrored afterthought. The usual failure mode is a design locked to English line lengths that breaks the moment Arabic copy arrives; the layouts here were built expecting both from the start.
Reporting that admits what it does not know
The owner dashboard reports contribution rather than revenue, priced from the per-item costs the venue enters, and counts only orders it can attribute to something the platform actually did — a pairing rule, an offer window, a campaign link, a second round. When cost coverage is incomplete, it says so beside the figure instead of rounding up. Building a reporting surface that reports its own gaps was a deliberate decision and, honestly, the hardest one to hold to.
Why this is in our portfolio
Because it is the one project a prospective client can audit. When we say we can build a multi-tenant platform with role-separated permissions and bilingual UX, the usual evidence is an anonymized paragraph. Here it is a URL. You can open the product, read the terms, look at the running screens, and form your own view of whether the engineering is any good.
It also changed how we scope. Operating a product — support, upgrades, migrations, the cost of a schema decision made two years ago — is a different discipline from delivering one. Client estimates that come from having lived with those consequences are better estimates.
What this case study does not tell you
It reports no venue's revenue, order volume, retention, or business outcome. Mihbaj is a commercial product with paying customers and pilot venues, and their trading data is not ours to publish. What is published is the architecture and the product itself, both of which you can inspect without taking our word for anything.
Frequently asked questions
Can I verify that Ijjad built this?
Yes, and more thoroughly than with any client project. Mihbaj is not a site we handed over and walked away from — it is Ijjad's own product, which we designed, built, and operate. The whole thing is live at mihbaj.com: the marketing site, the product screenshots, the Arabic version, the published terms. Most of our government and enterprise work sits under NDA and cannot be checked at all.
Why does an agency build its own product?
Because running a product teaches you things client work does not. Multi-tenancy, permissions, upgrade paths, support load, and the cost of a bad schema decision only really land when you own the consequences for years rather than weeks. When we scope a client platform now, the estimates come from having lived with those decisions rather than from a template.
What is technically interesting about it?
Three things. It is multi-tenant, so one deployment serves many venues with isolated data and per-venue configuration. It is role-separated: owner, manager, cashier, kitchen, and waiter each get a different workspace rather than one screen with hidden buttons. And every order is re-priced on the server before it is accepted, so a stale or tampered client-side price cannot be ordered against — a detail that matters more than any visual decision on the project.
How is the Arabic handled?
Arabic is a first-class layout, not a translation layer bolted onto an English design. Guest ordering screens, staff workspaces, and the marketing site all run in Arabic and English, with right-to-left handled as a real layout direction. There is a separate Arabic site you can open and read.
Does this predict results for my project?
No. This case study describes what we built and how it is architected. It does not report venue revenue, order volume, or business outcomes, and no engagement should be scoped on the assumption that a different product will behave the same way.
Can Ijjad build something like this for me?
Yes, and this is the closest thing we have to a technical reference for that conversation. If you are scoping a multi-tenant platform, a product with several distinct user roles, or anything that has to work bilingually in Arabic and English, open Mihbaj first and tell us which parts of it map to your problem.
Scoping a platform rather than a website?
Multi-tenancy, roles, permissions, and bilingual UX are decisions that are cheap now and expensive later. Open Mihbaj, tell us which parts map to your problem, and we will scope from there.
Get Started →Source note
Mihbaj is Ijjad's own product, so this page has a conflict of interest worth stating plainly: we are describing our own work. Everything asserted here is visible on the live product rather than reported from private records — open mihbaj.com and check it. No venue's revenue, order volume, or business performance is reported on this page.


