Project
Seher Yıldızı Turizm — a tour site running live with a real client
A tour agency's shop window and back office in one system: a visitor sees a tour and leaves a booking request, and the agency manages the traveller, their passport, their payments and their hotel room from that same record.
The problem
A small tour agency's work does not end with marketing. Publishing a tour listing is only the beginning; behind it sit booking requests, traveller details, passport and visa tracking, payments arriving in instalments, group lists and hotel room allocation. Most of this runs between WhatsApp messages and Excel files — and the same traveller's details end up stored in four different places.
The agency itself was not standing still either: the business started with Umrah tours and later opened up to general tour sales. That meant the site could not stay the way it was first built.
The solution
I brought the shop window and the back office together in a single Laravel application. On the visitor side there is a categorised tour showcase, narrowed down by city, date, duration, budget and whether a visa is included; the tour detail page holds the day-by-day itinerary, the hotels, what the price covers and a gallery. A booking request is left from that same page along with the travellers' names, and the visitor can then check its status with a booking number. The blog, FAQ, testimonials and contact form are managed from the same panel.
The real gain is on the management side: the moment the agency confirms a booking, traveller records are created automatically from the details in the request. The data is entered once, and from then on the passport details, visa status, payment history and room assignment all grow on that same record. Taking a payment, confirming or cancelling a booking are not separate screens but steps on the booking record itself.
The agency's move from Umrah to general tours was reflected in the data model too: the hotel city went from a fixed list to a free field, and tours gained a category, a currency and a destination. The old /paketler addresses were not deleted — they were moved to the new /turlar addresses with permanent redirects, so the URLs that had built up in search engines were not broken.
Technology
A detail worth highlighting
The most interesting screen in the panel is room planning. Distributing travellers from confirmed bookings into hotel rooms is a harder problem than it looks: rooms come in twos, threes and fours; groups should not be split; and the number of empty beds should be as low as possible. I automated it with the logic "place the largest group first, try to fit it into an open room, and open a new room if it does not fit" — a classic bin-packing approach, but its real value is not on the code side.
The real value is in the domain rule built into the algorithm: people from the same booking may share a room (they count as a family), while people from different bookings are only placed together if their genders match. No general-purpose packing library could know that rule, and it could not be written without talking to the agency. After the automatic allocation the agency can still move travellers by hand — the system decides, the human has the final word.
The visibility side
For an agency site, being findable matters more than a feature list. The sitemap and robots file are generated dynamically from the database; every tour and blog post enters the list the moment it is published. Tour pages are also exposed to search engines as structured data, and they announce it when a tour is fully booked. Fields such as the title, description, social image and analytics code are not baked into the code; they are fields the agency can change from its own settings screen.
Let's talk about a similar problem
If there is work to be delivered to a real client, or a process that needs to go digital, an email is enough.