Background

At events where guests have assigned tables, organisers usually pin a seating chart by the entrance or call out names one at a time. That builds a queue at the door, and the moment an assignment changes, the printed chart is out of date. I wanted to find out how simply this could be solved without a large application: one page a guest can open on their phone, and one panel for the organisers to arrange the tables.

Solution

I built Tempatin as a single PHP page whose contents change depending on who opens it. A guest presses the Check Table button, types their full name, and immediately gets their table number as a code such as A1 or C4. Once the number appears, the session is cleared straight away so the same device can be passed to the next guest.

Organisers come in through the same route, except the name they type is "Admin Tempatin". When that name matches, what appears is not the guest banner but the table management panel.

Key features

• Table lookup by name, with no login and no ticket number.
• A table grid whose rows and columns are set by the admin, not fixed in code.
• Assigning and clearing tables directly from the grid, without reloading the page.
• Colour coding: occupied tables green, empty tables red, and the occupant's name shown when a table is clicked.
• A layout that stays readable on a phone screen, since guests will almost certainly open it on one.

Technical challenges

The first problem came from free-form input. Names are typed by hand, so "Axa Rajandrya", "axa rajandrya", and "AxaRajandrya" all have to count as the same person. I normalise both sides before comparing: lowercase the letters, strip the spaces, then match. It works, but I took a shortcut by pulling the whole table and comparing in PHP. For a guest list of one event that is still light. For thousands of rows it clearly is not, and the normalisation should move into its own indexed database column.

Second, how to store table positions. I split them into two columns: meja_baris holds a letter and meja_kolom holds a number. The A1 label is assembled in JavaScript with String.fromCharCode(65 + row index), then split again on the server with substr when saving or clearing. The split makes building the grid easy, but it caps the number of rows at 26 because the letter is a single character.

The weakness I am most aware of is admin identity. There is no user table and no password. The admin is recognised purely by the name "Admin Tempatin", which I store as one row in the table with position Z0 so it does not appear in the grid from A1 onwards. That means anyone who guesses the string can open the admin panel. For a small event whose link is only shared with attendees, I accept that risk. For wider use, this is the first part that has to be replaced.

One more thing I have not closed: the meja_baris and meja_kolom columns have no unique constraint. I only prevent clashes through the interface, where a button that is already green does not open the reservation dialog. If two admins press the same table at almost the same moment, the database will accept both.

My role

I did this project alone from start to finish: the database schema, every PHP endpoint, the grid logic in JavaScript, and the layout adjustments. The visual side is built on an existing SaaS HTML template whose contents I reworked for the application's needs. What is purely mine is the whole table flow and its data handling.

Results and what comes next

I have not used Tempatin at a real event yet. So far it stands as an exercise: I wanted to test whether one table and six PHP files are enough to solve one small need end to end, from the guest side to the organiser side. The answer is yes, with the caveats written in the challenges above.

If I take it further, the order of work is already clear. Proper admin authentication, a unique constraint on table positions, moving the name matching into the query, and an export of the assignment list so organisers have a copy outside the application.