UAE café ordering platform · Al Ain rollout
The bars above are the team's estimate of how much is built. This block is not an estimate: it is counted from the shipped source. A page can be finished and still be showing invented numbers — which is exactly what the super-admin portal was doing a week ago, on 22 of its 24 pages. That is now zero, and the block below is the count rather than a claim.
A Figma for the admin panel arrived on 17 August — the first design any of the web panels have ever had, covering 49 screens and 42 overlays. The bars above are about function: whether a thing works. The bars below are a different question — how much of each panel matches the approved design.
Written while building the admin panel, so every item is something that actually blocked or changed a build — not a wishlist. Frame ids are included so each one can be opened directly. The full screen-by-screen list is in the design request document.
We previously reported that five of your frames had the ledger’s column headings copied into them
and could not be built as drawn. That was our mistake, not yours. On re-reading the file on
19 August, Refunds, Vouchers, Fraud & Risk and Roles & Audit are each
exactly the screen its name says — a refunds table, a vouchers table, a risk board and a roles list.
All four are now built as drawn.
We had been checking screens against our own build notes rather than against your file. Re-checking
properly also turned up four screens we had reported as finished that did not actually match. Those
are corrected too. Nothing is outstanding from you on any of these.
Refunds 52:2432 · Vouchers 524:24920 ·
Fraud 135:21395 · Roles 190:20843
Café Payouts and Support Queue both appear in the admin menu and neither has a frame
anywhere in the file. We built both from your design system so the portal works, and they should be
replaced when they are designed.
There is still no café logo and hero control anywhere in the file, which is why twelve real
businesses show stock photography in the app.
Resolved: Manage Members 335:24709 — the frame lists your platform staff and the
desks they sit on, so it is now built against those rather than a single café’s team.
Approve on application review is drawn enabled next to “1/6 required docs verified”. We
disabled it until every required document is checked; as drawn, a café could be approved with an
unverified trade licence.
Sign-in errors are drawn per field. We show one message, because saying an email exists but the
password is wrong lets anyone test which addresses are registered.
Filter drawers are drawn as checkbox cards; we read that as multi-select, so “paused or
suspended” can be one view.
Café Review Ready and Rejected we read as two states of one screen rather than two screens, and
built the three the lifecycle actually has — documents submitted, under review, decided.
Failure states. Only sign-in has an error drawn. We have implemented the distinction
throughout the admin panel — every screen now separates “this failed to load, and here is why” from
“there is nothing here” — but the wording is ours, not designed. The earlier outage reached customers as
an empty list precisely because those two looked identical.
Expired documents. Review covers verified, uploaded and rejected, but a document that expired
between submission and review still needs a decision.
Empty-state wording. The frames have empty variants but generic copy. “No live orders right now”
reads very differently from “No orders”.
These are the only things holding work back that neither the developers nor the designers can produce. Each one has to be opened, bought or registered in your company's name. Everything below is already built and waiting for the credential — none of it needs new development once supplied.
Payment gateway (PSP). Card payments are simulated today — no money moves. Needs a live
merchant account. Blocks: real orders, payouts, refunds and the VAT report.
OTP / SMS provider. Sign-up and sign-in verification currently accept a fixed test code. Needs an
SMS or WhatsApp Business sender. Blocks: letting real customers register.
Firebase project (push notifications). Built end to end; every message is currently recorded
rather than delivered. Needs a Firebase project for com.pingo.app, its google-services.json and the FCM
key.
Google Maps API key. Blocks the map view in the app and the map panel on Service Zones.
Trade licence / commercial registration. Required by the payment gateway and both app stores
before an account can go live.
DUNS number. Required to register an Apple Developer organisation account — it is issued free by
Dun & Bradstreet but can take a couple of weeks, so it is worth starting early.
VAT registration (TRN). The platform already calculates and reports VAT per order; the number
itself has to come from you.
Company bank account / IBAN letter. Required for café payouts and by the payment gateway.
Apple Developer Program and Google Play Console accounts, in the company name. The
Android app is currently distributed as a direct download from pinuae.com, which is fine for testing but
cannot be how customers install it.
Both require the trade licence above, and Apple additionally requires the DUNS number.
Two data-privacy faults, found and fixed. A café’s full bank account number and your
customers’ full phone numbers and email addresses were being sent to the browser. Both were hidden on
screen, which is not the same as protected — the real values had already left the server. Both are now
masked at the source, and unmasking a customer’s contact details requires a written reason that is
recorded against the person who asked.
The audit trail now exists. This was the largest gap on this list a week ago: suspending a café,
approving an application or refunding an order left no record. Every admin action is now logged with
who, what and when, and past activity was reconstructed from the order and refund history so the trail
does not begin empty.
Fraud and dispute monitoring now exist too. Risk signals are detected from your real data and
disputes have a record of their own. Worth knowing: the risk board is empty today because the rules ran
and found nothing — not because nothing is watching.
One country or two — now a launch choice, not a blocker. Rather than wait on the answer we
built both. Service areas now carry their market: pick a UAE zone when adding a café and it asks for a
trade licence and municipality food licence; pick a Saudi zone and it asks for a Commercial
Registration, an SFDA permit and ZATCA VAT registration, and the phone code changes to +966. All we
need from you is whether Saudi should be visible at launch or hidden until later.
Café branding. Twelve real businesses currently show stock photography in the app because there
is no logo or hero image for any of them, and no screen to upload one. We need the artwork, and a
decision on whether cafés manage it themselves or you do.
Monitoring. Platform Health now reports order success and payment success from our own
data. Uptime and app response time still cannot be: nothing watches the service from outside it, and
an uptime figure calculated by the server being asked is worthless. Those two read as unavailable
rather than showing an invented number, and closing them means an external monitoring service.
Super-admin portal and branch console — 62 pages in TanStack Start. Barista tablet layout, order queue, detail pane, curbside cards and pickup-code flow.
Django REST API — 174 endpoints across auth, tenants, menu, orders, payments and scheduling. Multi-tenant data model, JWT auth and the order lifecycle state machine.
QA across all three surfaces — login flows per role, the full order lifecycle, menu edits, per-branch data isolation and on-device verification of the review build.
| Screen | Status | Next step by | Note |
|---|---|---|---|
| Onboarding · language, slides, welcome | Working | — | Live from the API |
| Sign up & sign in · 10 screens | Working | — | OTP flow complete |
| Home feed | Working | Design | Promo card repeats its title; category labels need final copy |
| Store & item detail | Working | — | Real menu, prices and modifiers |
| Orders list & history | Working | — | Reads real orders |
| Basket | Blocked | Mobile | Does not submit the order — no API call at all |
| Place order | Blocked | Mobile | Animation only; navigates to a fixed order id |
| Order tracking | Partial | Mobile | Reads real status but never refetches |
| In-order chat | Missing | Mobile + Backend | UI built, not connected |
| Tipping | Missing | Mobile + Backend | UI built, not connected |
| Search | Partial | Mobile | Map renders; result list incomplete |
| Rewards / Pins | Partial | Backend | Static — loyalty engine not built |
| Rate order, favourites, profile edit | Partial | Mobile | Saved to the device only |
| Taste quiz | Partial | Mobile + Backend | Answers posted but don't personalise the feed |
| Featured brands | Working | Design | Card art needs a photo, not the logo mark |
A Figma for the admin panel arrived on 17 August — the first design any of the web panels have ever had. As of 19 August every screen in it is built and matches it: colours, type and spacing, navigation, and every list and detail screen with a working filter panel. We then re-checked all of them against the file a second time, which found four we had wrongly reported as finished. Those are now done too.
It opened the week with 2 of 24 pages reading the real system and 22 pages of convincing placeholder figures. Every page now reads the real system and none shows invented numbers. Revenue, orders, customers, cafés, refunds, vouchers and support tickets are all real — and where a figure genuinely has no source, the screen says so instead of inventing one.
Checking every screen against the design turned up faults that were already live: the order filters did nothing at all, the portal signed users out at random while they clicked between pages, and — the two that mattered most — a café’s full bank account number and your customers’ full phone numbers were being sent to the browser. Both are now masked before they ever leave the server.
Rather than wait on the one-country-or-two question, we built both. Choosing a Saudi zone when adding a café switches the required documents to Commercial Registration, SFDA permit and ZATCA registration, and the phone code to +966. If you would rather launch UAE-only, we hide it — the work is done either way.
A café can now be reviewed and approved from the portal: the queue shows who is waiting and for how long, each document can be verified or rejected with a reason the café will see, and approval is blocked until every required document has been checked.
The Support Queue reads real tickets with their full conversation, and replies go back to the customer. Resolve, close and reopen all work. None of this was connected before — the screen showed example tickets.
Eight separate places were showing invented figures as though they were real: a performance chart that
was a formula, three invented staff names, invented fraud alerts and disputes, made-up order timings and
per-item prices, and an audit trail that reset whenever the page reloaded. All removed. Two pages that
would have crashed outright were also fixed.
Four of those have since been rebuilt for real (19 Aug): the café performance chart is now one bar
per day counted from actual orders, the fraud board runs real detection rules, disputes have a record of
their own, and the audit trail is permanent and was backfilled from your order and refund history.
All five code repositories are on GitHub under your own account, and the previous developer's remotes have been removed so nothing can be pushed there by accident. The design documents are published alongside the app code; the three containing live passwords are deliberately kept out.