Most point-of-sale software is built for one kind of business. You buy the restaurant one or the retail one, and if your shop doesn't fit your needs, you bend the shop to fit the software.
Nula starts from the opposite assumption - that a supermarket, a restaurant, and a barbershop all fundamentally have the same needs. Someone is choosing things, seeing the total, taking payments. Only the surface around that needs to change.
It fits any scenario: the same core product becomes a scan-first supermarket, a table-side restaurant, or a touch-led barbershop. It runs on any screen: an iPad, a terminal, as well as the display that faces the customer, and an app on your phone.
Most point-of-sale software is built for one kind of business. You buy the restaurant one or the retail one, and if your shop doesn't fit your needs, you bend the shop to fit the software.
Nula starts from the opposite assumption - that a supermarket, a restaurant, and a barbershop all fundamentally have the same needs. Someone is choosing things, seeing the total, taking payments. Only the surface around that needs to change.
It fits any scenario: the same core product becomes a scan-first supermarket, a table-side restaurant, or a touch-led barbershop. It runs on any screen: an iPad, a terminal, as well as the display that faces the customer, and an app on your phone.
Most point-of-sale software is built for one kind of business. You buy the restaurant one or the retail one, and if your shop doesn't fit your needs, you bend the shop to fit the software.
Nula starts from the opposite assumption - that a supermarket, a restaurant, and a barbershop all fundamentally have the same needs. Someone is choosing things, seeing the total, taking payments. Only the surface around that needs to change.
It fits any scenario: the same core product becomes a scan-first supermarket, a table-side restaurant, or a touch-led barbershop. It runs on any screen: an iPad, a terminal, as well as the display that faces the customer, and an app on your phone.
The product finder: scan, weigh, or look up by code, see the lane and shift that's open. For restaurants, it would be tables.
The item: tap any product and it opens into the same controls: quantity, discount, price override, remove.
The close: subtotal, tax, total. And one confirming action - a supermarket charges, a restaurant settles a bill.
The product finder: scan, weigh, or look up by code, see the lane and shift that's open. For restaurants, it would be tables.
The item: tap any product and it opens into the same controls: quantity, discount, price override, remove.
The close: subtotal, tax, total. And one confirming action - a supermarket charges, a restaurant settles a bill.
The product finder: scan, weigh, or look up by code, see the lane and shift that's open. For restaurants, it would be tables.
The item: tap any product and it opens into the same controls: quantity, discount, price override, remove.
The close: subtotal, tax, total. And one confirming action - a supermarket charges, a restaurant settles a bill.
The room as the interface
Take a restaurant, for example. Instead of scrolling through a list of menu items, it’s as though looking at a map: a digital version of the dining room, presented in 3D. The tables you’re serving aren’t only numbers on a screen; they’re right where you’d expect to find them.
The room as the interface
Take a restaurant, for example. Instead of scrolling through a list of menu items, it’s as though looking at a map: a digital version of the dining room, presented in 3D. The tables you’re serving aren’t only numbers on a screen; they’re right where you’d expect to find them.
The room as the interface
Take a restaurant, for example. Instead of scrolling through a list of menu items, it’s as though looking at a map: a digital version of the dining room, presented in 3D. The tables you’re serving aren’t only numbers on a screen; they’re right where you’d expect to find them.
The map has two states. It zooms into the table you're serving - the screen above - and sits wide the rest of the time, surveying the whole floor - the screen below. What moves the system between them is the interesting part.
At rest: When nothing needs attention, the map is wide and empty. You can see the floor at a glance, and the interface saying there's nothing to do.
Our testing showed a very specific failure. A waiter serving one table would miss another table's request - they'd finish, go back to the bar, check the tablet, and only then find another table had been waiting. So when a new table needs something, the map zooms out of the table close-up to the wide view. Two things happen: the waiter sees at a glance where the new request is, and - the part that actually made a difference - the movement itself catches their eye mid-task. A busy waiter registers motion in their periphery even before they'd read a notification pill. The map doesn't just show the floor. It moves to be noticed.
Our testing showed a very specific failure. A waiter serving one table would miss another table's request - they'd finish, go back to the bar, check the tablet, and only then find another table had been waiting. So when a new table needs something, the map zooms out of the table close-up to the wide view. Two things happen: the waiter sees at a glance where the new request is, and - the part that actually made a difference - the movement itself catches their eye mid-task. A busy waiter registers motion in their periphery even before they'd read a notification pill. The map doesn't just show the floor. It moves to be noticed.
Our testing showed a very specific failure. A waiter serving one table would miss another table's request - they'd finish, go back to the bar, check the tablet, and only then find another table had been waiting. So when a new table needs something, the map zooms out of the table close-up to the wide view. Two things happen: the waiter sees at a glance where the new request is, and - the part that actually made a difference - the movement itself catches their eye mid-task. A busy waiter registers motion in their periphery even before they'd read a notification pill. The map doesn't just show the floor. It moves to be noticed.
When the floor fills up: The order panel's still open - mid-service on Table 24 - while three other tables light up with different needs: [yellow = ready to order, green = ready to pay, red = needs assistance]. New tasks are arriving on top of current work, which is exactly when the zoom out is built for.
The map's state isn't constant, and pretending otherwise would be dishonest. It helps new staff through the weeks of learning where "Table 24" physically is; it fades to a pleasant background once that's muscle memory; it earns its keep again on the nights an experienced employee's head is on fire and motion beats memory. And, most importantly, it acts as a subconscious indicator that lets the waiter work without losing focus on the other tasks.
The map's state isn't constant, and pretending otherwise would be dishonest. It helps new staff through the weeks of learning where "Table 24" physically is; it fades to a pleasant background once that's muscle memory; it earns its keep again on the nights an experienced employee's head is on fire and motion beats memory. And, most importantly, it acts as a subconscious indicator that lets the waiter work without losing focus on the other tasks.
The map's state isn't constant, and pretending otherwise would be dishonest. It helps new staff through the weeks of learning where "Table 24" physically is; it fades to a pleasant background once that's muscle memory; it earns its keep again on the nights an experienced employee's head is on fire and motion beats memory. And, most importantly, it acts as a subconscious indicator that lets the waiter work without losing focus on the other tasks.
The same idea doesn't belong everywhere. It's used at full scale in a restaurant, a supporting role in a barbershop, and no place at all in a supermarket - where all spatial versions we tried traded speed for nothing particularly useful.
A sale that's decided in advance
A supermarket doesn't know what's in the basket until it's scanned. A barbershop knows everything before the customer sits down. The service, its length, and its slot are all chosen at booking - so here the sale isn't discovered at the counter, it's arranged ahead of time. The finder becomes a booking: what, for how long, and when.
A sale that's decided in advance
A supermarket doesn't know what's in the basket until it's scanned. A barbershop knows everything before the customer sits down. The service, its length, and its slot are all chosen at booking - so here the sale isn't discovered at the counter, it's arranged ahead of time. The finder becomes a booking: what, for how long, and when.
A sale that's decided in advance
A supermarket doesn't know what's in the basket until it's scanned. A barbershop knows everything before the customer sits down. The service, its length, and its slot are all chosen at booking - so here the sale isn't discovered at the counter, it's arranged ahead of time. The finder becomes a booking: what, for how long, and when.
The floor is here too, and it looks much like the restaurant's - deliberately, it's one product. But it's doing less: in a restaurant the 3D view tells a waiter something a flat list can't; in a barbershop you can see the open chair at a glance, so the map is consistency, not necessity. The same language, a lighter load. Payment closes it the way the other shops do, with one service-trade wrinkle — the barber can take it up front or after the cut. (We also prototyped the inverse, where the barber attaches the service at the chair rather than the customer at booking: more protection against under-charging, less control for the customer.)
One source, underneath everything
Every surface so far - the supermarket's scan, the restaurant's floor, the barbershop's booking - has been reading from the same place. This is it. It's not just a random dashboard on the side, but the layer the whole system depends on: every product is defined by what it's made of, and every surface gets knowledge from here.
One source, underneath everything
Every surface so far - the supermarket's scan, the restaurant's floor, the barbershop's booking - has been reading from the same place. This is it. It's not just a random dashboard on the side, but the layer the whole system depends on: every product is defined by what it's made of, and every surface gets knowledge from here.
One source, underneath everything
Every surface so far - the supermarket's scan, the restaurant's floor, the barbershop's booking - has been reading from the same place. This is it. It's not just a random dashboard on the side, but the layer the whole system depends on: every product is defined by what it's made of, and every surface gets knowledge from here.
That idea answers two different questions from the same data. Forward, it's readiness: if you run out of something important and the dish comes off the menu, run out of something optional, and it stays on, with a note for the waiter. Backward, it's depletion: if a portion of Alfredo takes roughly 300g of chicken, the system estimates, roughly, how much chicken is left and when to reorder. It's built as rough estimates on purpose: it's a signal to restock, not an automatic thing. It's the same layer, connecting the kitchen to the stockroom.
That idea answers two different questions from the same data. Forward, it's readiness: if you run out of something important and the dish comes off the menu, run out of something optional, and it stays on, with a note for the waiter. Backward, it's depletion: if a portion of Alfredo takes roughly 300g of chicken, the system estimates, roughly, how much chicken is left and when to reorder. It's built as rough estimates on purpose: it's a signal to restock, not an automatic thing. It's the same layer, connecting the kitchen to the stockroom.
That idea answers two different questions from the same data. Forward, it's readiness: if you run out of something important and the dish comes off the menu, run out of something optional, and it stays on, with a note for the waiter. Backward, it's depletion: if a portion of Alfredo takes roughly 300g of chicken, the system estimates, roughly, how much chicken is left and when to reorder. It's built as rough estimates on purpose: it's a signal to restock, not an automatic thing. It's the same layer, connecting the kitchen to the stockroom.
The same truth, at the table: This is the restaurant order screen from earlier. When a waiter adds a Caesar, the system already knows anchovies are out of stock because inventory said so - and offers the recipe's own substitution: capers and a splash of fish sauce. Two parts of the back office, inventory and recipes, are creating one answer that the waiter can rely on without going back to the kitchen.
