The catalogue has an obvious contradiction in it. Three apps are built on a rule that data should not leave the device. The fourth, CafePOS, is a cloud service where the data has to leave the device — that is the entire point.
That is not a change of philosophy. It is the same rule applied honestly: keep data as close as the job allows, and be explicit when the job requires otherwise. A restaurant is a different job from a photo library.
The short answer
- The studio’s constraint is data minimisation, not local processing at any cost.
- Personal tools — screen time, media, documents — work on one device, so they run on that device.
- A POS is shared by the counter, the kitchen and the owner at the same time, so its state has to be shared too.
- CafePOS is therefore a cloud product with an account; the Android apps remain offline and account-free.
- The obligation is to say which is which, plainly, before someone installs or subscribes.
What the three apps have in common
ScrollBreak measures how long protected apps are in the foreground. ReelRoll reads the media library and renders video. ScanLocker captures pages, runs OCR and writes encrypted PDFs. In each case the data is created on the phone, used on the phone, and useful on the phone.
None of them needs a server to do its job. Adding one would create a copy of something sensitive for no functional gain — a photo library, a screen-time history, a passport scan. So there is no account, no upload and no cloud queue. The privacy policy can be short because the architecture is short.
Why a POS cannot work that way
A cafe at 8pm is not one person using one device. It is a counter taking orders, a kitchen receiving them, a floor being rearranged, and an owner who may be at home. All four need the same answer to “what is open, what is running out, and what did today earn?”
That is a shared-state problem. If the counter’s device holds the order and the kitchen’s device holds a different version, the system has failed at the exact moment it matters. A local-only POS could work for a single till with no kitchen screen and no remote owner, but that is a smaller product than the one most cafes need.
So CafePOS keeps the order, the bill, the stock and the customer record in a service. The counter, the kitchen and the owner read and write the same record. The trade is real and worth naming: the vendor holds the restaurant’s operating data, and the restaurant depends on a connection.
What we did not trade away
The cloud decision is not a licence to be vague. The questions a cafe should ask are the same ones we would ask:
- What is stored, and where? Orders, menu, tables and reports are needed to run the service. A POS does not need your customers’ biometrics or your personal photo library.
- Who can see it? Staff roles should be scoped, and the owner should know what a manager can export.
- Can I get it out? A menu, customer list and sales history should be exportable. Leaving a POS should not mean abandoning the business’s records.
- What happens when the connection drops? Ask for the fallback before service, not during a rush.
- How long is it kept after cancellation? “Forever” is an answer, and it should be a documented one.
Those are not marketing questions. They are the difference between a cloud product that respects the business and one that merely stores it.
The same rule, different distances
It helps to think in terms of distance rather than ideology:
| Product | Where the data lives | Why |
|---|---|---|
| ScrollBreak | On the phone | One person’s usage history; no shared state |
| ReelRoll | On the phone | Media and renders; uploads would add risk, not value |
| ScanLocker | On the phone | Documents and OCR; the vault is local and encrypted |
| CafePOS | In the service | Shared orders, tables and reports across a team |
The first three are private tools. The fourth is an operating system for a small business. Treating them the same would be simpler to describe and worse to use.
Where CafePOS fits
We build CafePOS, so read this as a product description.
CafePOS covers billing, dine-in/takeaway/delivery orders, tables, inventory, customer records and sales reports in one web-based POS. It is aimed at cafes, quick-service restaurants, fine dining and other food businesses, and it is configured with the team rather than sold as a download.
It is not the right product if you need a system that runs entirely offline, and we would rather say that here than in a support ticket. Visit cafepos.in or email contact.cafepos@gmail.com to book a demo.
If you are evaluating a POS, the practical guides go deeper:
- What a cafe POS does — and what to check before you buy
- GST billing for cafes: what the bill has to carry
- Table management for a cafe: a floor plan that survives a rush
The test for the next product
The catalogue will probably grow again. The question to ask is not “can this run on the device?” but “where does the data have to live for the job to work, and what is the smallest footprint that makes it work?”
For a personal tool, that answer is usually the phone. For a shared business system, it usually is not. Saying so plainly — in the product page, the schema, the FAQ and the privacy policy — is the part that does not change.