Most hospitality software you can buy off a shelf was designed around a particular picture: a dining room, numbered tables, a server who takes an order at the table, courses that arrive in sequence, a bill split three ways at the end, and a tip. It is a good picture. It is also not what most food businesses in Malé are doing.
A large share of them are counters. Short eats and tea in the late afternoon, takeaway all evening, one or two people serving, a queue that appears in fifteen minutes and disappears again. Software built for the dining room does not fail on a counter. It just asks for things that are not there, and every one of those questions costs a few seconds at the worst possible moment.
What the dining room model assumes
- That every order belongs to a table, so it asks which one
- That a server owns the order, so it asks who
- That ordering and paying are separate moments, so it opens a tab
- That courses matter, so it groups the ticket
- That tipping is normal, so it prompts
On a counter, four of those five are a keystroke you do not need, and the fifth is a screen you have to dismiss.
What a counter actually needs
Watch a hedhikaa rush and the requirements write themselves. The order is short and repetitive. The customer is standing in front of you. Payment is immediate and mixed between cash and card. The bill is one line of thought, not four.
So the till needs the twenty things you actually sell within one tap, on a grid rather than in a list. It needs to complete a sale in as few actions as possible. It needs to let one bill wait while you serve the next person, because somebody always comes back to add a juice. It needs to sell a tea and a short eat as one button while still taking both off stock. And it needs to print small and fast.
The measure that matters in a food business is not how many features a screen has. It is how many taps a normal sale takes, multiplied by two hundred sales a day.
The part that is not on the screen at all
Closing is where a food business finds out whether the software is any good. Two questions at the end of the night: what came in, and does the cash in the drawer agree with what should be there. If answering those means exporting something and comparing it by hand, nobody will do it after the third night, and the shop goes back to guessing.
Where the imported product still wins
We are not arguing that foreign hospitality software is bad. If you run a resort restaurant with table service, covers, split bills and a kitchen display, a mature product built for exactly that will beat anything general. The mistake is buying that product for a counter and then paying for its assumptions every afternoon.
The reverse mistake exists too. A simple counter till in a full service restaurant will have your staff writing on paper within a week.
How we approach it
When we fit software to a food business the first thing we do is stand at the counter during the busiest hour and count. Not interviews, not a requirements document. Counting taps, watching where the queue stalls, noticing which item somebody has to search for every single time. Everything after that is negotiable. That hour is not.
The same subject from the other side of the counter, written for the person using the till rather than choosing it, is on the product's own blog: a POS for cafes and restaurants in Male.
RekordPOS is built on the counter model, and it is honest about it. If you run a dining room and need table service, tell us and we will say so rather than sell you the wrong shape. If you run a counter, let us watch your busy hour.