About
What this is for
A hospitality operating system built for the places that cannot afford for it to be fragile — and a statement of what we are trying to do, written so that somebody can hold us to it.
Most systems tell you what happened. ROSFlow can prove it — every bill, every void, every tax number, checked rather than trusted.
Mission
To give an independent restaurant the operational spine a chain takes for granted — and to keep it running on the evenings the internet does not.
Present tense, because a mission is what the thing is for today. The two halves are not decoration: the operational spine is the product, and the evenings the internet does not cooperate are the reason the terminal holds its own orders rather than trusting the line.
Vision
That any restaurant in India can open on Monday and be running a complete, auditable operation by the weekend — without a consultant, a server cupboard, or a single line of anybody else's code.
Deliberately falsifiable. "By the weekend, without a consultant" is a claim somebody can time with a stopwatch and tell us we failed — which is the only kind of vision worth printing, and the thing the guided setup is measured against.
How we get there
Three, because a strategy that lists seven is a wish list. Each is a decision the software can be checked against, so a reader can call us on it.
1
It works when the line drops
A restaurant does not stop when its broadband does. Orders are taken, held and reconciled on the terminal itself, and the bill that comes out of a night spent offline is the same bill as any other night. Most systems at this price treat the connection as an assumption; we treat it as weather.
2
Nothing is a placeholder
A GSTIN is checked against its own check digit before it can reach an invoice. A figure the system cannot verify says so rather than showing a confident zero. Every cross-tenant act is written to an audit trail the venue can read without asking us. Software that quietly guesses is worse than software that admits what it does not know.
3
One pass for every order
A dish that goes off in the kitchen goes off on Zomato and Swiggy too. Delivery orders arrive on the same pass as the dine-in ones instead of on a separate tablet nobody is watching. The fragmentation is the problem worth solving; a faster till is not.
Who it is for
Independent restaurants, bars and small groups in India — the places with between one and a dozen rooms, a real kitchen, and nobody whose job title is IT.
Saying who a thing is not for is part of a strategy rather than a caveat on it. A national chain has an IT department and a procurement process; both are good reasons to build something other than this.
How it is built
Plain PHP and MySQL, with no third-party framework and no package manager in the dependency path. That is an unfashionable choice and a deliberate one: it means the whole system runs on the shared hosting a single restaurant already pays for, and the same code runs on a small machine in the venue when the connection cannot be relied on.
It also means there is no supply chain to audit. Everything that runs is in one repository, and the things that are not finished are written down as plainly as the things that are — the Security page has a section listing what is still open, for the same reason this page carries a panel when its own copy has not been approved.
The company
ROSFlow is the product — the thing you sign into, the name on the till and on this website. ROSFlow LLP is the company that builds it: the entity on a contract, an invoice or a notice, and the one named in the Terms.
They are deliberately not interchangeable. A brand cannot be sued, invoiced or served notice, and a legal entity does not belong on a login screen. Everywhere the software refers to itself it says ROSFlow; the registered name appears only where somebody needs to know who they are contracting with — Contact, Terms, Privacy, Refunds, and the copyright line at the foot of this page.