What I Learned Building Software for My Uncle’s Hotels
I began with a simple idea: improve how two small hotels record bookings and track their work. It soon became a lesson in how complicated a 24-hour business really is.
In an earlier post, I wrote about helping with my uncle’s hotels in Guwahati.
One of the properties had recently been taken over on lease after years of poor management and weak maintenance. The new team could repair rooms and improve service, but guests searching online would still see the hotel’s old photographs, reviews, and reputation.
My first instinct was to focus on marketing. We could use social media, Google, and a better website to show that the hotel was under new management.
But that led to a basic question:
If we spend money on marketing, how will we know which activity actually produces a booking?
The existing hotel software could not give us a dependable answer. It was old, difficult to use, and staff members did not always enter information consistently. Important details were scattered across the software, registers, phone calls, and WhatsApp messages.
So, with my uncle’s permission, I started building a hotel web application as a self-directed project.
I thought I was building a better booking system.
I soon realised I was trying to represent an entire 24-hour business.
A guest creates a chain of work
From the guest’s point of view, staying at a hotel appears simple: book a room, check in, sleep, pay, and leave.
Behind the reception desk, the journey is much longer.
Enquiry → Booking → Room assignment → Check-in → Stay
→ Food and other services → Payment → Checkout
→ Cleaning → Room ready for the next guest
Every step affects another part of the hotel.
If a guest changes rooms, the old room must be marked for cleaning and the new room must become occupied. If the guest orders dinner, the kitchen needs the order and the charge may need to appear on the room bill. After checkout, housekeeping must prepare the room before reception can sell it again.
A mistake in one place can quickly spread to another.
That is why the application gradually grew beyond bookings. It now connects front-desk work, room status, housekeeping, maintenance, restaurant orders, guest bills, payments, and daily reporting.
The room grid is the hotel’s shared picture
The most important screen is a grid showing every room.
Each room can be vacant, occupied, dirty, ready, blocked, or under maintenance. These colours are not merely visual labels. They tell the staff what can happen next.
| Room status | What it means in practice |
|---|---|
| Vacant and ready | Reception can sell the room |
| Occupied | A guest is currently staying there |
| Dirty | The guest has left and housekeeping must clean it |
| Blocked | The room is being held and should not be sold |
| Maintenance | A problem must be fixed before the room returns to use |
Suppose a guest moves from Room 206 to Room 301. The system must move the guest and their stay to Room 301, mark Room 206 as dirty, preserve the bill, and keep a record of the change.
Simply editing “206” to “301” is not enough.
This gave me one of the project’s main principles:
The room grid must show what is physically true inside the hotel.
If the software and the building tell different stories, staff will stop trusting the software.
A hotel day does not always end at midnight
One of the strangest things I learned was that a hotel’s working day is not necessarily the same as the calendar day.
Imagine a guest arriving at 1:30 a.m. The date on the computer has changed, but the night team may still be closing the previous day’s accounts.
If the software follows only the clock, it can place the guest on the wrong day or add a room charge incorrectly.
Hotels solve this through a process called the night audit. The team checks the day’s rooms, charges, payments, and cash before formally moving the hotel to the next working date.
11:00 p.m. 12:00 a.m. 1:30 a.m. Night audit
└────────────── same hotel working day ────────────► closes
The application therefore keeps a separate hotel working date. It also protects against accidental double charging. If someone runs the night process twice, the same room rent should not be added twice.
This sounds like a small rule. In reality, it affects bills, reports, payments, and every occupied room.
A room bill collects charges from many places
A final hotel bill may contain much more than room rent.
The guest may pay an advance, order food, request an extra bed, use laundry, receive a discount, or ask a company to pay part of the bill. Payment may happen through cash, card, UPI, or company credit.
The application needs to collect these entries in one running guest account while remembering where each charge came from.
Room rent ───────────┐
Restaurant order ────┤
Laundry and extras ──┼──► Guest account ──► Payment and invoice
Discounts ───────────┤
Advance payments ────┘
This is particularly important for the restaurant. A single meal may create three records:
- An order for the waiter.
- A kitchen ticket for the cook.
- A charge on the guest’s room account.
Those records must agree with each other even though different employees use them.
One small group-booking error changed the design
Some of the best lessons came from errors.
Consider a company booking four rooms. Three rooms are charged at an agreed company rate, while one room is free for a tour leader or senior guest.
In an early version, the “complimentary” setting was too closely connected to the whole booking. Making one room free could affect the price of the other rooms.
The correct structure looks like this:
Company booking
├── Room 301 — paid
├── Room 302 — paid
├── Room 303 — complimentary
└── Room 304 — paid
The solution was not simply to add a warning message. The application had to store the rate and payment rules separately for every room.
This taught me an important product lesson: when a simple click creates a serious mistake, the problem may be underneath the screen rather than on it.
Why the system works inside the hotel
The application uses modern web technology, but its daily hotel functions are designed to work through the property’s local network.
Reception computers and restaurant tablets can connect to a computer inside the hotel. A temporary internet problem should not stop the front desk from finding a reservation or checking in a guest who is waiting at 2:00 a.m.
Reception ──────┐
Restaurant ─────┼──► Hotel’s local system ──► Shared information
Housekeeping ───┘
The internet is still useful for the public website, online bookings, backups, and future integrations. The idea is simply to protect essential hotel work from avoidable internet interruptions.
The software must fit the real reception desk
Software often looks excellent on the large screen used by its developer.
A real reception desk may have a smaller monitor, several windows open, a ringing phone, a printer nearby, and a tired guest waiting for a key.
That environment changed my design decisions. Important buttons need to remain visible. Tables should show enough information without constant scrolling. Staff should recognise the words used on screen. Printing a bill or kitchen ticket should take seconds, not several confusing steps.
The goal is not to create the most fashionable interface. It is to help someone complete a task correctly while several things demand their attention.
Testing the complete guest journey
Checking individual pages is not enough. The application must also survive the full journey across departments.
One of the main tests follows this sequence:
Guest checks in
↓
Guest changes rooms
↓
Guest orders food
↓
Food is added to the room bill
↓
Nightly room charge is added
↓
Guest pays and receives an invoice
↓
Guest checks out
↓
Housekeeping cleans the room
↓
Room becomes available again
This reveals problems that may not appear when each screen is tested separately. A room move affects housekeeping. A restaurant order affects the final bill. Checkout affects whether the room can be sold again.
Automated checks help catch repeatable errors, but staff testing is equally important. Employees reveal confusing language, unnecessary steps, printing problems, and real situations that I did not imagine while developing the system.
New software does not automatically create good data
I began this project because the old system did not give us dependable information. But a better application cannot solve that problem by itself.
If staff members skip the booking source, we still cannot measure whether Google or Instagram produced the reservation. If maintenance complaints remain only in WhatsApp, management cannot see repeated problems. If a cashier shift is not closed properly, the daily figures will not be trustworthy.
The application must make correct data entry quick and clear. The hotel must also decide:
- which information is compulsory;
- who is responsible for updating it;
- how mistakes are corrected;
- which reports management checks; and
- what to do when the software and physical reality do not match.
Building the tool is only half the job. The other half is building the habit of using it properly.
Where the project stands now
After more than sixty focused development iterations, the application is moving into live testing.
It is not a finished success story. The next phase is to run it beside real front-desk and restaurant work, compare system figures with actual cash balances, test invoices and kitchen tickets on physical printers, and watch where employees hesitate or find workarounds.
Later, the hotel websites and booking journey can connect with the system. That will bring the project back to the question that started everything:
Discovery → Enquiry → Booking → Stay → Feedback → Improvement
▲ │
└────────────── better decisions ───────────────┘
If we record that journey correctly, we can learn which marketing attracts useful bookings, which problems keep repeating, and whether operational improvements are actually changing guest experience.
What I have learned so far
I thought the difficult part would be choosing the technology. The harder part was understanding the hotel well enough to represent it accurately.
I learned that a room is not simply vacant or occupied. A hotel day does not necessarily end at midnight. One booking may contain several rooms with different prices. One guest bill may receive charges from several departments. And a beautiful dashboard is meaningless when the information underneath it is incomplete.
Most importantly, I learned that business software is not only about screens and features. It is about creating a shared version of reality that employees can trust.
This began as an attempt to improve data collection at my uncle’s hotels. It is gradually becoming a connected operating system for reservations, rooms, food, payments, staff handovers, and management decisions.
Whether it eventually becomes useful beyond our two properties will depend on what happens during real-world testing.
For now, the aim is simpler: help the hotel run each day with fewer gaps between what happened, what was recorded, and what management believes happened.
A note about the project
This is a personal, self-directed project at my uncle’s hotels, undertaken with his permission. I am not the owner and do not present myself as an experienced hotelier. The hotel names, guest information, addresses, and commercially sensitive details have been omitted. The software is entering live testing and should not yet be understood as a completed commercial product.
Written by Bijesh Singha
I work across financial analysis, product strategy, data, and technology. This project is where those interests meet the everyday reality of running a hospitality business.