Skip to content
Horulabs

Nyusulapp

From one free seat to a played table.

Nyusulapp fills mahjong tables. A host posts, players join, seats commit on a schedule, and a parlor locks the physical table. The till runs on the same record, even when the internet drops.

How a table runs now

6 steps

  1. PostHost opens a table
  2. JoinPlayers take seats or waitlist
  3. LockA parlor table is reserved
  4. ConfirmRSVP and standby windows
  5. PlayOpen bill at the till
  6. SettleBill closed, seats marked

The next table starts with each seat's standing

One table, from post to closed bill. Cancellations, no-shows and disputes run beside this path.

A game came together in a group chat.

One person asked, three said maybe, and the fourth never showed. The table was booked by message, the seat was held by hope, and nobody carried the cost of the empty chair.

Parlors kept bookings in a paper book and took cash at the till. The booking and the bill were two records that never met, so a table could be double-booked and a bill could be lost.

When the internet dropped, the till stopped with it. The room was still full; the software was not.

The booking and the bill became one record.

A table is the unit of work on both sides: players fill it, the parlor locks it, the till bills it.

BeforeAfter
  1. Booking by chat

    One table record

    Seats, venue, time and level in one place, shareable back into the group chat.

  2. Paper table book

    Parlor availability

    A full table reserves a real parlor table, with walk-ins and open play on the same floor view.

  3. Cash till, separate book

    Open bill per table

    Food, drink and other goods stay on the table's bill until it closes.

  4. Re-typed takings

    Queued sync

    The offline console keeps working and sends its writes when the connection returns.

  5. No consequence for a no-show

    Reliability ledger

    A 100-point standing, confirmed reports, and a cooldown give the empty seat a cost.

Two sides, one loop.

Players and parlors work on the same tables and the same schema. A design that helps one and complicates the other was rejected.

  1. Matchmaking with a deadline

    Create, join and leave a table; first-come waitlist; RSVP opens at T-12h, standby at T-4h, auto-cancel at T-1h. The host can cancel, participants can be removed.

  2. A reliability ledger

    A 100-point standing per player. No-shows are confirmed by at least two participants, and the consequence is visible before the next join.

  3. The parlor console

    Floor view, bookings, walk-ins, table availability, rates and promos. A public booking page and parlor page let the venue share one link.

  4. POS and the offline appliance

    An open bill per table at the till. The Android-wrapped console queues sales offline and syncs back, so a dropped connection does not stop service.

  5. Notifications that move a seat

    Web push for table full, need-N-more, reminders at 12, 4 and 1 hours, auto-cancel and a waitlist opening. Each table also has a chat.

  6. Discovery that respects distance

    Nearby tables and parlors sorted by road distance, with a straight-line fallback. The empty state seeds a new city instead of showing nothing.

A phone for players, a till for the parlor.

The player surface is thumb-first. The console is dense and must survive an internet drop. Both run on one Next.js app and one Postgres schema.

Next.js · React
Player app, parlor console, admin panel and public booking pages.
Supabase · Postgres
Auth, data, realtime refresh and the seat, booking and match rules.
Self-hosted OSRM
Road distance for nearby discovery, with a straight-line fallback.
Web Push + PWA
Installable player app and notifications, including the Android console wrapper.

Seats that commit, tables that get played.

One system for booking, table locks and the POS, with an open bill per table for F&B and other goods. It keeps working offline, and it remembers who showed up.

  • A full table locks a real parlor table instead of a promise.
  • The till and the booking share one record, so neither is re-typed.
  • A dropped connection delays the sync, not the service.
  • The next table starts with every seat's standing already known.

Client

Nyusul

A mahjong table-filling product for players and parlor operators in Indonesia, live at nyusul.com. Players use it on a phone; parlors use the console at a tablet or a back-office PC.

Send one workflow. We'll look at it with you.

Tell us the task that costs your team the most hours, and how it runs.

The first conversation is free, with no commitment.