A platform that allows venues to manage reservations and their day-to-day operations from a single system.
Built and online · Venue management · Reservation management · Venue operations · Payment tracking · Staff workflows · Customer records
The problem
In many venues, reservations are managed in one place, schedules in another, and payments are recorded separately. By the end of the day, it can become difficult to know which reservations actually took place, which sessions are still active, and which payments have been completed.
What I built
A unified platform for managing reservations, sessions, and payments. The goal is to replace multiple disconnected tools with a single system that keeps the venue's daily operations connected from reservation to payment.
Why it matters
A reservation becomes an active session, the session is completed with a payment, and at the end of the day the shift's financial records can be reconciled with the activity recorded in the system. This keeps the entire process connected and traceable from the moment a reservation is created until the payment is completed.
My role
Heselo is my own product. I designed and built the entire platform independently — including reservations, the live floor interface, payments, inventory, and administration screens. The product is built and available online. It has not yet been released for commercial use, so no venue currently runs its daily operations through Heselo.
Heselo · online
Venue management
Worked example · Heselo
One operational fact, three states
A reservation, a live session and a payment are not three apps. They are three states of the same record.
Reserved
The resource is promised for a window. Another booking cannot silently take it.
guest arrives
Live
The guest is here. Time is running. Products can be added.
session settles
Closed
The session has a total, a tender, and the shift it belongs to.
What the system refuses
×A second booking taking a window already promised
One reservation record follows the entire process: reservation → session → payment
One shared database
The reservation, the session created from it, and the final payment are treated as different stages of the same record. This approach helps prevent the same time slot from being promised twice and keeps payment records from different shifts from becoming mixed together.
Built with: Java · Spring Boot · REST APIs · PostgreSQL · React · Docker
