Reservations that still hold at 21:00

Venue software fails in a specific way. The schedule looks fine at noon. At nine, two groups arrive for the same room, a walk-in is already sitting there, and the cash drawer does not match the sessions that were never closed.

Spreadsheets and WhatsApp chats do not have a conflict model. They have optimism. Heselo exists because a reservation, a live session and a payment are three states of the same operational fact — not three apps.

The states that matter

• Reserved: the resource is promised for a window. Another booking cannot silently take it.
• Live: the guest is here. Time is running. Products can be added.
• Closed: the session has a total, a tender and a shift it belongs to.

If those states are not explicit in the data model, the UI will invent them. Operators will “just move it” in a way the system cannot reconstruct tomorrow. History is not a nice-to-have in a venue. It is how you explain the drawer.

Correctness before cleverness

I care about the unglamorous parts: overlapping intervals, protected past days, a cash shift that does not mix with the next one, and actions that need a confirmation code because they rewrite money. Java and Spring Boot are a good place to put that logic because it is easier to test a reservation conflict in a service than to hope the frontend remembers.

A product people actually use is one that still tells the truth after a messy night. That is the bar.