Everything below runs on the live system with Link Lounge Cafe set up as a real café: its full menu
of 88 items with the photos from linkloungecafe.com, its logo and storefront, drink sizes and milks,
curbside bays and a promo code. It is open around the clock while you test; we will set it back to
its real hours (7 AM – 12 AM) when you tell us testing is finished. Sign-in details for the café tablet and
the owner come to you separately and are never published on this page.
Order as a customerStep 1
Install the Android app from pinuae.com and sign in. Open Link Lounge, add an Iced Spanish Latte (choose Large and Oat milk) and an Egg Benedict, apply the code LINKLOUNGE10 (10% off), choose Curbside, enter your car and place the order. When you arrive, tap “I've arrived”.
Make it on the counter tabletStep 2
Open branch-demo.pinuae.com on a tablet and sign in with the Link Lounge café account. Tap Omar (or Maya), choose a 4-digit PIN, then take the order through Accept → Start Preparing → Mark Ready → Handoff, using the pickup code shown in your app. Chat with the customer from the order screen.
Run the café as the ownerStep 3
On the tablet, tap Manage (or “Owner login” on the sign-in screen), choose the manager and set a PIN. The first time, you confirm it with that account's password. Then look at the Dashboard, open the order in Orders (lifecycle, timeline, what the café earns, and Issue Refund), check Earnings, and switch an item off in Menu: the app shows it as sold out.
Try it in ArabicStep 4
Switch EN | عربي on the sign-in screen or in the manager header and repeat any step. The Arabic wording is our draft, so please mark anything that reads wrong.
Tell us what you foundStep 5
For anything that looks wrong, send a screenshot, what you expected, and which step you were on. Please also confirm the Link Lounge prices: 75 of the 88 are placeholders we set because the website lists AED 0.00 (we can send you the price list with those highlighted). Payments are in test mode, so no real card is charged.
Completion by area — function (team estimate)
Backend API95%
Super-admin portal97%
Branch / café console90%
Barista tablet94%
Android customer app96%
Overall94%
Measured — how much runs on live data
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.
Customer app — on live data100%
Café console & barista — on live data63%
Super-admin portal — on live data100%
Customer app — 46 of 46 screens. Real accounts, real orders, real loyalty; orders placed in the app arrive in the café console. The exception is PRO membership, which is a mockup — see below.
Café console & barista — 19 of 30 pages. The tools your cafés use
every day are genuinely wired to the backend. On 13 September the barista tablet's remaining sample
orders, sample menu and invented staff names were removed and replaced with live data; this figure will be
re-counted with the next update rather than guessed now.
Super-admin portal — every page. This finished on 19 August. The portal opened the week with 2 of 24 pages reading the real system and 22 pages of convincing placeholder figures; there are now none. Every screen either shows your real business or states plainly what it cannot show and why. The demo records held in the browser are gone entirely.
Progress by panel — against the approved design
A Figma for the admin panel arrived on 17 August — the first design any of the web panels
have ever had. On 10 September your designers delivered the MASTER files for both the web
panels and the customer app, which added the finished barista tablet, two admin screens and a revised
customer app. We compared every frame of the new files against the previous versions before building,
so the work below is exactly what changed. 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.
Admin panel — built to the design85%
Admin panel — running on live data100%
New on 13 September — 29 of 34 screens. The MASTER file added designs
for Café Payouts and the Support Queue, the two menu items that previously had no screen. Both
are now built to their frames. Café Payouts shows the next batch, what is pending and the last batch paid,
and Run Payout Batch is real: it shows you the cafés and the exact amount before anything is created,
then schedules one payout per café for the following Monday. No batch has been run. The other 27 screens
did not change in the new file, which we confirmed frame by frame.
27 of 32 screens built · every one of them now matches your design · all of them run on your real business. The count has not moved this week, and that is the honest picture: what changed is the quality of the 27. Four screens we had reported as finished did not actually match their frames, and three more we had reported as “impossible to build from the frame” turned out to have been misread on our side. We re-checked every frame against your file rather than against our own notes, and corrected all seven. The five screens still outstanding are listed below and none is waiting on us.
Working end to end: sign-in, Command Centre, Platform Health,
Transaction Ledger, Cafés, Live Order Monitor, Customers, Service Zones, VAT & Taxes,
Prayer & Calendar, Promotions, Refunds, Vouchers and issuing one, Roles, Manage Members,
Support Queue with real ticket replies, Café Payouts, all five detail screens, and the complete café
onboarding flow — queue, application review, per-document verify and reject, and the approve decision.
Every list has a working filter drawer.
We extended your backend where the design needed more rather than fake
the numbers: café counts per zone, per-customer spend and order metrics, an onboarding queue reporting
market, owner, documents and waiting time, and platform-wide lists for payouts, refunds and vouchers.
Almost none of it was new logic — the capability was already written and simply had nothing exposing it.
All additions; no data changed; the customer app was unaffected throughout.
Fraud & Risk and Disputes are now real features, not just real screens. Both were previously showing invented alerts that never changed, and we replaced them with screens that said the feature did not exist. On 19 August we built it: risk signals are now detected from your actual data — customers with repeated refunds, several accounts sharing one phone number, bursts of failed payments — and disputes have a record of their own. The risk board is empty today because the rules ran and found nothing, which is a different statement from “we are not looking”.
The five that remain, and why.Sign-in step two is a verification code screen with no second factor behind it — building the screen without the mechanism would be a login box that accepts anything. Free-item and buy-one-get-one vouchers need pricing rules the order engine does not have: a free-item code has to point at a menu item, and buy-one-get-one has to count baskets. They are missing mechanics, not missing fields, and the other three voucher types are built. The two café application frames returned no field content when we read them, so we have asked your designers for a corrected export.
Barista tablet — built to the designBuilt · final check pending
Café manager console — built to the designBuilt · final check pending
Café owner panel — built to the designOwner sign-in built · multi-branch views not designed
Barista tablet — built on 13 September. The finished design arrived
in the MASTER file and the tablet was rebuilt to it: staff choose who is on shift and sign in with a
personal 4-digit PIN, then work orders through New → Accepted → Preparing → Customer Arrival → Ready →
Collected, with the line items, curbside car and bay, and a chat with the customer. The 86 menu really
switches items off in the app, and the pickup code is now genuinely checked — before, any four digits were
accepted. Every sample order, menu and staff name was removed; everything shown is your live café. The tablet now also runs in Arabic, right to left (see below).
Café manager console — designed on 19 September and built to it.
Your designers delivered the Manager portal: 35 screens, with a right-to-left version of each. The manager now
works on the counter tablet. They sign in with Owner login and a personal PIN, and one switch moves
between Manage and Live Orders. All nine designed pages are built on your live data:
Dashboard, Orders, a full Order Details page, Menu (items, modifier groups, add and edit item), Pricing
& Hours, Promotions, Analytics, Earnings and Settings. Order Details shows the order's lifecycle and
timeline and the café's commission and net. From there a café can print a ticket, refund an order (the
refund comes out of the café's share) or cancel it. The tablet also knows its own name
(“Counter T-01”, “T-02”), and Settings lists every paired tablet.
Café owner panel. The new design covers the owner signing in at the
counter. The views an owner uses across several branches (all branches, payouts by branch, team) are
still not designed. They keep working under “More” in the side menu.
Staff tools. The barista PIN sign-in now clocks staff in and out, which is
the first staff tool connected to a design. Roster, leave and the manager's view of attendance still have
no design.
Customer app — built to the design98%
46 of 46 screens built · 45 traceable to a specific approved frame.
The one that is not is Favourites, which has no design — it was built from the design system instead.
Updated to the MASTER design on 13 September. Home is now a feed —
Hot / Cold, category stories and posts of each café's popular drinks — and the navigation is Home, Explore,
Orders and Profile, with Rewards reached from Profile. Store, Quiz, Order Tracking and Profile were brought
in line with the revised frames. A new build is on pinuae.com. Two parts of the new file are not built:
Pin AI, which needs a decision on the AI service behind it, and the Arabic version of every
screen, which needs Arabic copy.
PRO membership is still pending. The screens are built and match the
design — the upsell sheet and the PRO dashboard both exist. But subscribing does not do anything: it
flips a switch inside the app for the rest of that session, takes no payment, tells the server nothing,
and is gone on the next launch. There is no PRO plan, no billing, and nothing that checks whether a
customer is actually PRO. Making it real needs the payment gateway in the list below, then the plan,
the renewal and the member benefits.
Also still open: notification delivery to a locked phone, the map view,
and card payments — each waiting on an item in the list below rather than on design or development.
What we need from the design team
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.
Five screens are not built, and none is waiting on development.
Three of the five need something from design.
Café Application — no field content in the frame. Reading these frames
returns buttons and nothing else, so there is nothing to build from. We need a corrected export, or a
list of what the merchant-facing form should collect. 01 Form — Empty 336:25271 · 01 Form — Filled 346:31098
· 02 Confirmation 354:41351
Sign In step two — no second factor exists. The screen is a verification
code, but sign-in returns straight to the portal after email and password. Is two-factor actually wanted?
If so it is a backend feature before it is a screen. 02 Verification — Empty 5:8661 · Filled 5:8680 ·
Error 5:8699
Free-item and buy-one-get-one vouchers. The platform supports a flat amount or
a percentage. A free-item voucher needs to point at a menu item and buy-one-get-one needs quantity logic
when the basket is priced — both are pricing rules, not form fields. Both tabs are shown disabled with the
reason. Free Item 557:30028 · B1T1 557:31430
Withdrawn: “five frames we cannot build”
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
From the MASTER file — please look at these
Featured Brands has lost its way in. The new Home no longer links to it, so the screen cannot be
reached. Where should it sit?
Café Payouts filter804:38728 lists payment statuses (Pending, Captured…). A payout is
scheduled, on hold, paid or failed — we built those.
Support Queue quick replies read “On it now / Ready in 2 min / At the counter”, which is barista
wording in an admin screen. Built as drawn; confirm or re-word.
Reject an order on the barista tablet has no reason list, and the customer app has no screen for a
rejected order. Both sides need the same list of reasons.
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.
Four choices we changed — please confirm
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.
States the frames do not cover
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”.
What we need from you
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.
Accounts & services to open
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.
Company documents
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.
Store accounts for publishing
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.
Three things worth your attention
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.
Decisions only you can make
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.
Team
F
Faiz
Frontend developer
Super-admin portal and branch console — 62 pages in TanStack Start. Barista tablet layout, order queue, detail pane, curbside cards and pickup-code flow.
J
Jamshaid
Backend developer
Django REST API — 198 endpoints across auth, tenants, menu, orders, payments and scheduling. Multi-tenant data model, JWT auth and the order lifecycle state machine.
A
Abdullah
Testing
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.
Android app — screen status
WorkingPartialWaiting on a decision or credential
Screen
Status
Next step by
Note
Onboarding · language, slides, welcome, quiz
Working
—
Quiz updated to the MASTER design
Sign up & sign in
Working
Client
Uses a fixed test code until an SMS provider is opened
Home feed
Working
—
Rebuilt as the MASTER feed; posts are each café's popular drinks
Store & item detail
Working
Client
Real menu and prices; photos are stock until cafés upload their own
Basket & place order
Partial
Client
Orders are real and reach the café; card payment is simulated
Order tracking
Working
—
Live status; order summary card from the MASTER design
Curbside arrival & chat with café
Partial
Development
The tablet side is built; the app does not yet send “I've arrived” or show café replies
Orders list & history
Working
—
Reads real orders
Rewards, stamps, catalogue
Working
—
Real pins and stamps, managed from the café console
Profile, settings, vehicles, support
Working
—
Saved to the account
Pin PRO
Partial
Client
Screens built; no plan or billing behind subscribing
Explore map view
Waiting
Client
Needs a Google Maps key
Pin AI
Waiting
Client
Designed; needs a decision on the AI service
Arabic (right-to-left)
Waiting
Client
Designed; needs Arabic copy
Featured brands
Partial
Design
Built, but the new Home no longer links to it
Since the last update
The café console and tablet speak Arabic
Every café screen can now switch to Arabic with EN | عربي on the sign-in screen and in the manager
header. That covers the manager pages, settings, staff and the barista tablet. Right to left, the whole
layout mirrors the way your designers drew the RTL screens. The Arabic wording is our draft and needs your
review. Each tablet remembers its language.
The 19 September designs were checked first
Your designers sent three files. We compared each one with what we had already built. The customer
app and the main web file are exactly the same as on 10 September. The new file adds the café
Manager portal and two small tidy-ups that needed no rebuild.
The café Manager portal is built
Owners sign in on the counter tablet with a PIN, then switch between managing the café and watching
live orders. All nine designed pages run on your live cafés. Nothing that worked before was removed:
rewards, staff and shifts are under “More”.
Cafés can refund, and see what they earn per order
Each order now shows its payment the way a café sees it: subtotal, PinGo commission and net to
the café. The café can refund an order itself, in full or in part, with a reason. The refund is
recorded against the café's share and written to the audit log.
Numbers now follow Dubai time
Daily figures used to split at midnight UTC, which is 4 a.m. in the UAE, so late orders were
counted on the wrong day. Days are now Dubai days. Average preparation time is now measured from
your real orders, not left blank.
What happens next
Try the barista tablet at a real counterCritical
Client · it is built and live on branch-demo. Two things need your decision first: who sets each barista's PIN (today the first person to tap a name sets it), and the list of reasons a café can give when it rejects an order.
Decide on Pin AI and send Arabic copyHigh
Client · both are designed and are the two largest parts of the MASTER file not yet built. Pin AI needs the AI service chosen; Arabic needs the translated copy, as right-to-left changes the layout as well as the words.
Tell us what is wrong with the admin panelHigh
Client · every screen has now been checked in a browser, signed in, rather than only typechecked — which is how the seven live faults were found. What we cannot check is whether it does what you actually need. Please click through it.
Try the Manager portal on a counter tabletHigh
Client · on the barista sign-in screen tap “Owner login”. The first time, each owner chooses a PIN and confirms it with their PinGo account password, so nobody at the counter can take over an owner's PIN. Three things need your decision: may cafés issue refunds themselves (built, paid from the café's share); which integrations you actually want (Foodics, Zoho Books, WhatsApp are shown as “Not connected”, because none exists yet); and VAT is not yet recorded on payments, so it shows AED 0.00.
Confirm the prayer-time method and calendar rulesMedium
Client · prayer times are now calculated for Al Ain rather than the fixed Dubai times the design showed. Confirm which calculation method should be authoritative, and give us the Ramadan and Eid trading rules.
Open the accounts the platform is waiting onHigh
Client · payment gateway, OTP provider, Firebase and a Maps key. Everything behind them is already built — see “What we need from you”.
Decide what a dispute and a fraud signal areMedium
Client · both now exist in the system — a dispute record and a risk board fed by real detection rules. What we invented is the plumbing, not the policy: we still need your definition of what counts as a dispute here, what states it moves through, and who decides the outcome. The rules currently watch for repeated refunds, shared phone numbers and failed-payment bursts — tell us what else should raise a flag.
Review the Arabic wording in the café consoleMedium
Client · the café console and counter tablet now run in Arabic, and the Arabic wording is our draft. Please have an Arabic speaker click through it (switch with EN | عربي on the sign-in screen) and send corrections. Roster, shifts, attendance and leave still have no design input.
Outstanding on the customer appMedium
Development · the app does not yet tell the café “I've arrived” for curbside orders or show the café's chat replies — the tablet side of both is built. Featured Brands needs a new place in the design.