Direct-booking platform for a hotel
Hotel The Manha
A boutique hotel in Dhaka took every booking by phone or walk-in. I designed and built its direct-booking platform: a guest site with a guided reservation flow, and a backend that runs rooms, availability, invoices, and email.
- Ownership
- Client work
- Organisation
- Hotel The Manha Ltd, Dhaka (solo engagement)
- My role
- Designer and full-stack engineer, solo
- Status
- Delivered in 2025
- TypeScript
- Next.js
- Express
- MongoDB
- Resend
Overview
Hotel The Manha sits in Purana Paltan, the commercial centre of old Dhaka. Guests booked by phone or in person. There was no online channel and no way to show rooms to travellers searching for them.
The goal was a guest-facing site that feels as considered as the hospitality it sells, and a backend that runs the hotel's real operations: rooms, availability, bookings, guest verification, and email. I designed and built both sides.
Role and ownership
What I personally did
- Interface design for the guest site and booking flow.
- Next.js guest site with a guided date and guest picker reused across four surfaces.
- Express and MongoDB backend for rooms, availability, blocked dates, seasonal pricing, and bookings.
- Branded PDF invoices and transactional email through Resend.
Constraints
- Solo engagement: design, frontend, backend, and deployment by one person.
- Availability depends on several layers at once: confirmed bookings, dates the hotel blocks, seasonal price overrides, and room status.
- Most guests arrive on phones, so the booking flow had to work at 375px with no horizontal overflow.
Solution
One guided component turns check-in, check-out, and guest count into a single flow. Each field opens a popover under itself with a step rail across the top, and a live summary counts nights as you go. The same component powers the home hero, the room page, the reservation form, and the listing filters.
The API filters each room's bookings at the database level, and the client merges those ranges with per-date overrides to price each night individually. On submission, the server checks availability again before confirming.
A single branded PDF generator feeds the download endpoint, the confirmation email attachment, and the booking-management page.
Guest site
Next.js
Guided date and guest picker
Manage booking
Email + reference lookup
API
Express API
Availability re-check on submit
Invoice generator
One PDF, three surfaces
Data and email
MongoDB
Rooms, bookings, overrides
Resend
Confirmation with PDF attached
Key decisions
Re-check availability at submission
Two guests can look at the same free night at the same time.
- Considered
- Trust the availability the calendar showed when the page loaded.
- Chose
- The server checks availability again at the moment of submission and rejects the booking if the dates were taken.
- Trade-off
- A guest can occasionally lose dates at the last step, which is far better than a double-booked room.
One invoice generator for every surface
Guests need proof of booking in the email, on the success page, and later when managing the booking.
- Considered
- Separate templates for the email, the download, and the web receipt.
- Chose
- One backend PDF generator feeds all three surfaces.
- Trade-off
- The email path depends on PDF generation, but an invoice change lands everywhere at once and the surfaces never drift apart.
Lookup needs email and reference together
Guests return to view or cancel a booking without an account.
- Considered
- Look up bookings by email address alone.
- Chose
- Require the booking reference as well as the email.
- Trade-off
- One more field to type, but an email address alone reveals nothing about anyone's stay.
Outcome
The hotel takes bookings directly online instead of relying only on phone calls and walk-ins.
Invoice changes land in the email, download, and management page at once.
Responsive down to 375px with no horizontal overflow, checked with device-emulated audits.
Reflection
Date pickers are where booking sites usually break. Building one component and reusing it everywhere meant fixing a bug once instead of four times.