Three surfaces, each with a job it is better at than the other two — and two platforms we do not support, with the reason for each written down rather than left to be discovered.
Every decision in this product assumes the till is a handset held in one hand with cash in the other. The browser is genuinely useful and it is genuinely secondary — a shop that never opens it is missing nothing that records a sale.
You and your staff, at the counter
This is the product. Everything that records a sale happens here, on the phone that is already on your counter, whether or not there is a network.
You, when you have a real keyboard
Not a second till — a second view. It exists for exactly the three jobs a five-inch screen makes miserable, and it does not do billing at all.
Your customers, on any device
A plain web page per shop, so it opens on anything with a browser — an old Android, an iPhone, a laptop. Nobody has to install anything to see what you have.
Written for the handset already at the counter, not for a new one. If your phone runs WhatsApp, it runs this.
The app is built with a toolkit that can produce an iOS build, so this is a question of cost rather than a rewrite: an Apple developer account, a Mac to build on, and a review process, all before the first shopkeeper installs it. India's small-retail counter is overwhelmingly Android, so the pilot is where the shops are. It is not a refusal — there is simply no date to promise, and inventing one would be worse than saying this.
This one is a decision, not a gap. A Windows billing counter is a second product with its own offline-sync bugs, aimed at a shop that has a desk, a chair and someone sitting at them — which is not the counter this is written for. The browser covers the desk work; billing stays on the phone. If a pilot shop asks twice, unprompted, for something they genuinely need a computer to do, that specific thing gets designed. The general request does not.
That is the whole requirement list.
