Abdullah Hanif

Engineering Notes

Case studies with numbers

Two write-ups from production work on Xero Sphere AI: how WhatsApp orders avoid Meta Cloud API lock-in, and how search holds up at one million products on a small VPS.

WhatsApp orders without Meta Cloud API fees

Usual path

Teams burn months on Meta Cloud API verification and then pay ongoing message costs for basic customer notifications and order flows. For a Pakistani restaurant that already lives on WhatsApp, that tax is real.

What I built instead

A native Android APK with a background Notification Listener Service, plus NDK where performance mattered. The phone intercepts incoming order texts, decodes them, and pushes structured orders into the central SQLite WAL database — same ERP the POS already uses.

Result

Orders run on ordinary Android hardware. No Meta verification gate for this path. Message cost for that pipeline: $0. Independence from Meta's monetization funnel for day-to-day order taking.

Why NDK + listener, not a script

This isn't a fragile chatbot glued to a webhook. It's an order-taking stack: notification engine, voice STT where needed, Order Mode vs Friend Mode, parallel chat handling. NDK sits under the hot path so the device stays responsive when nights get busy.

Honest limits

This design trades Meta's managed API for device ownership and OS permissions. You need a dedicated shop phone, careful battery/permission handling, and ops discipline. I don't claim "unlimited free WhatsApp forever for every use case" — I claim a production order path that shops can run without Meta Cloud billing for those messages.

Product page →

Five cashiers, one million products, one vCPU

I don't claim speed without measuring it. Date: 3 Jan 2025. Branch 901. SQLite WAL, 64MB cache, DB ~946.5MB on 1 vCPU / 1GB RAM.

Question

Can 4–5 cashiers search the same 1M catalog on one small VPS without the UX falling apart?

Answer: Yes. Five parallel users, cold search aggregate p95 50ms (gate ≤100ms), user-to-user spread 1.88× (gate ≤2×), 0 HTTP errors.

PASSED 5 users @ 1M on 1 vCPU

Parallel search (cold)

UserSamplesp50p95max
Cashier 1251ms44ms58ms
Cashier 2251ms47ms47ms
Cashier 3252ms75ms77ms
Cashier 4252ms55ms69ms
Cashier 5252ms40ms50ms
Aggregate2ms50ms77ms

WAL stress

Five background inventory writes while five cashiers search.

  • Writes: 5 txns, 0 errors
  • Search p95 under write load: 100ms (gate ≤150ms)
  • HTTP errors: 0

Live browser proof

Playwright against app.xero-sphere-ai.com (branch REAL-1M-901).

  • POS prefix + FTS: PASSED
  • Inventory search: PASSED
  • CSV export ~3.2MB: 2225ms

POS path — typo queries

QueryServer msEngineRowsPOS-safe?
pndl56msnone0Yes
pnadl2msnone0Yes
pandl1msnone0Yes
pandol3msfts20Yes

POS uses prefix (≤2 chars) + FTS trigram (≥3 chars). Heavy Levenshtein stays off the POS hot path.

What I claim vs what I don't

Claim

  • 5–10 POS terminals on 1 vCPU @ 1M products
  • Prefix + FTS typeahead on POS
  • 64MB SQLite cache shipped in production

Do not claim

  • Thousands of simultaneous writers
  • Heavy fuzzy search on every keystroke
  • Default SQLite cache on a ~1GB DB

Real pharmacy load looks like 5–10 POS plus occasional stock-in. This test matches that — not a fantasy of infinite writers.