KAROBAR · PART 1 · SEPTEMBER 2026
Karobar began with a request from Mark, who runs a restaurant in Melbourne, Australia. Mark wanted billing and shop software for markets like Australia and Europe that staff could use in English or Urdu, because many of the people working there are comfortable in both. It sounds simple. Most of the month went on deciding what to test first, and where.
Billing and shop software requested by a restaurant owner in Melbourne, tested first with Pakistani shops, and now growing into an international SaaS product for Australia and Europe.
A restaurant owner in Melbourne asked for simple billing software that staff could use in Urdu or English. We built it as a subscription product from the first month, and tested it on one demanding market before going wider.
Shop software lives or dies at the counter. A bill has to take seconds, on a cheap phone, with a queue waiting. We chose Pakistani shops as the first test because the conditions are hard: mixed languages, patchy internet, credit kept in notebooks and a wide range of shop types. If the flow survives there, it should be comfortable anywhere else.
So the first version speaks Urdu and English, and its money and dates follow Pakistan. That was a deliberate shortcut for the test, and part 3 of this diary is about undoing it.
We did not build one shop’s app and convert it later. By 17 September the system already had plans with limits and feature permissions, and shop management for a super admin. Subscriptions, trials and a grace period followed two days later, then membership payments and receipts.
Having worked through a late move to SaaS on another project, we knew what it costs. Putting the plans in first means every later feature only has to ask one question: does this shop’s plan allow it?
The order mattered: the rules of the service came first, then the shop’s daily work.
If a product will be sold by subscription, build the plans first. Every feature added afterwards gets its limits for free.