AyByay is a live production system holding real shops' daily takings, their stock, and their customers' credit. This page states exactly how that data is held, on what basis, and what we will never do with it — with nothing claimed that the running build cannot back up.
The promise this whole page keeps: every number here is pulled from live tenant databases, and the exact SQL is available on request. Nothing appears on this page that a query cannot reproduce in front of you. Where a figure has a caveat, we print the caveat — because the honesty is the diligence.
The simplest, truest framing of the whole arrangement — and the one that decides every question below.
Processing rests on performance of the service contract with the shop (running its POS, stock and ledger) and the shop's legitimate interest in operating its own business. Customer-facing SMS reminders add a consent gate on top (§2). We are the processor; the shop is the controller of its customers' data.
Bangladesh's comprehensive Data Protection Act is still in draft as of 2026; we do not claim certification under any regime we have not been audited against. What we describe here is the posture the running system actually enforces.
A shop OS needs a customer's name and a phone number to run a baki ledger and send a reminder — so that is essentially all the customer PII we hold. We do not ask a shopkeeper's customers for national ID, address, date of birth, or payment-card data, and the product has no field for them.
The most sensitive data the platform touches is a shopkeeper's customer's phone number, attached to money owed. Here is its entire life inside AyByay.
The shopkeeper adds a customer's name + phone to their own baki ledger — the same information they already keep on paper.
It lands in that one shop's isolated database (§3). No cross-shop customer table exists to leak it sideways.
The number is used to send the baki reminder the shopkeeper chooses to send — nothing else. It powers no ad, no third-party feed.
Consent gate before sendThe shop can edit or remove a customer; on account closure the shop's data — customers included — is exported and deleted (§5).
Reminders are sent by the shopkeeper to their own customers — AyByay does not message a shop's customers on its own initiative, and does not use those numbers for its own marketing. During the current pre-launch phase, the live SMS gateway is pinned to a test recipient so real customers are not messaged before go-live — a deliberate safety catch, not a limitation to hide.
AyByay is a database-per-tenant system: each shop's data lives in its own database, not in a shared table filtered by a shop-id in application code. Isolation is structural, not a WHERE clause someone could forget.
This is the same boundary that makes the honest funnel below reproducible: each shop's numbers come from that shop's own database, queried in isolation.
The public demo runs on a dedicated tokenized link with a read-only demo role. It cannot create sales, edit stock, send messages, or reach another tenant's data. The write-block and endpoint blocklist are live-verified, not assumed — because a demo anyone can open is exactly the surface an attacker probes first.
An investor or partner can open the demo and try to break it without any risk to a real shop's data. The demo is deliberately walled off from the tenant databases above — the cheapest thing to verify, and we made it verifiable on purpose.
We state recovery honestly: automated encrypted backups and a written restore runbook exist. We do not claim a formally tested RPO/RTO SLA we have not measured — that is a milestone the raise funds, not a badge we wear early.
A shop's data is exportable through a backup/export endpoint — the shopkeeper is never locked in, and can carry their sales, stock and customer records out. Owning your own history is also the switching cost that keeps us honest about earning renewal.
Because each shop is a separate database, closing an account means removing that shop's data at its own boundary — customers, ledger and all — without touching any other tenant. Individual customer records can be edited or removed by the shop at any time.
A trust page that only lists what we do is half a page. These are the lines the business is built to hold.
We are pre-revenue by design. The only rows in the payments table are two SSLCommerz sandbox ৳299 test charges on an empty, zero-sale test shop, placed six minutes apart on 2026-07-15 — integration testing, not revenue.
We show you this so you don't find it in diligence and wonder what else was hidden. Surfacing it is worth more than the two charges ever could be. The seed exists to answer the only two questions that carry money — will a shop pay, and will it stay — not to dress up a number we don't have.
Selective transparency reads worse than full disclosure, so the empties are on the list too. One definition throughout: active = at least one sale in the trailing 7 days.
Detail: jamaltara & banbro in real use · alnoor early (4 products, 3 sales) · ziadsshop, rizzatrading, smcommunication, luvensy signed up but not yet onboarded. Comped plans, zero billed — never presented as paying customers.
৳5.04M inventory, at-cost, import day — AI-mapped from a PrimeERP export in one session, billing the same day. Described strictly as onboarding proof; it billed on 7 days then went quiet, so we never call it "daily use."
The platform holds real shops' daily data, built solo. That is both the achievement and precisely why continuity matters — a single-operator system carrying other people's data is a data risk, not just a hiring gap, and we treat it as one.
Every internal figure on this page traces to a live tenant-database query, stored so it can be run in a screen-share. Every external comparison in our wider materials carries its publication, year and scope. If a number can't survive a live query or a named source, it is not on the page.
Good. That's what this page is for. Ask for the SQL behind any number, or open the write-blocked demo and try to break it. Nothing here is meant to survive only until you look closely — it's built to survive exactly that.