Booking operations
Customers can search rooms, create bookings, pay online, and view booking history from one flow.
Overview
What is QuickStay?
QuickStay is a PHP and MySQL hotel management system that brings reservations, room availability, billing, and user roles into a single workflow.
Hotel management
Clerks and managers can handle room allocation, walk-ins, check-in, checkout, invoices, and reports.
Project Snapshot
Context, ownership, and delivery state
Quick context, ownership, and current build state.
One hotel workflow, four role-based views.
Bookings, room state, payments, and front-desk actions stay inside one shared system.
Use case
Hotel booking plus desk operations.
Audience
Managers, clerks, guests, and companies.
Scope
Small and medium hotel workflow coverage.
Operational hotel flow
Reservations, invoices, services, and payments stay linked instead of spreading across separate tools.
Full-stack build
UI, PHP booking logic, MySQL structure, and Stripe checkout all belong to the same project build.
HTML/CSS/JS
PHP
MySQL
Stripe
Working case study
Usable today, with webhook verification, notifications, and admin responsiveness as the next polish layer.
Prototype
Local runtime
Hardening next
Tech Stack
Stack used in the QuickStay build
Stack grouped by responsibility instead of a flat tech list.
Case-study interface and user flow presentation.
HTML, CSS, and JavaScript shape the portfolio narrative, the customer-facing journey, and the role-based workflow presentation across the page.
HTML
CSS
JavaScript
Server-side booking logic
Reservation flow, invoice creation, session-based login, and stay lifecycle handling run through PHP.
PHP
Sessions
Relational reservation state
MySQL keeps rooms, users, reservations, invoices, payments, and company-linked bookings in sync.
MySQL
Relational schema
Checkout and protected writes
Stripe handles payment sessions while prepared statements and CSRF checks protect sensitive requests.
Stripe API
Prepared statements
CSRF
Local delivery setup
Apache and XAMPP provide the current environment for developing and running the project locally.
Apache
XAMPP
Problem
Why the system exists
Hotels that rely on separate tools for bookings, billing, and staff access create friction at every handoff.
01
Room board
101
204
204
305
402
504
Availability
Room conflicts
When online requests and front-desk bookings are not synced, staff can accidentally assign the same room twice.
02
Billing flow
Services + tax
Total mismatch
Billing
Billing mistakes
Invoices, services, discounts, taxes, and advance payments are easier to lose when they are handled outside the booking flow.
03
Role access
Manager
Clerk
Customer
Company
Permissions
Weak role separation
Managers, clerks, customers, and travel companies need different tools, but the same source of truth.
Solution
One platform for every workflow
All booking operations, billing, and staff workflows unified in a single system.
Connected reservation flow
Search, booking, payment, invoice, check-in, checkout, and room status remain linked from the first request to the final bill.
Access Control
Manager, clerk, customer, and travel company users each land in the correct workspace with the right permissions.
Manager
Clerk
Customer
Travel Company
One operational path
Front desk and online workflows use the same booking records, so staff can see availability, payments, invoices, services, and guest movement without switching systems.
Shared booking source of truth
Operational Impact
Designed workflow outcomes
These cards explain the operational improvements the system is designed to create when bookings, billing, and permissions stay connected.
01
Lower room-conflict risk
Availability stays tied to the reservation record, so online requests and front-desk actions are less likely to compete for the same room.
Availability stays authoritative
02
Cleaner billing accuracy
Room charges, services, taxes, discounts, and advance payments stay in one invoice path instead of being reconciled manually later.
Billing follows the stay record
03
Better role clarity
Managers, clerks, customers, and companies can operate on the same booking data without exposing the same actions to everyone.
Shared data, scoped actions
User Roles
Four roles, one system
Manager
Manager
Controls rooms, services, reports, staff workflows, billing, and company accounts.
Clerk
Clerk
Handles front-desk bookings, check-in, checkout, reservations, services, and billing.
Customer
Customer
Searches rooms, books online, pays through Stripe, and manages reservation history.
Travel Company
Travel Company
Creates group bookings, assigns guest details, and manages corporate billing.
Features
What is built
Grouped capabilities, not a long checklist.
Core journey
One reservation spine across search, booking, payment, and stay.
Guests and staff move through the same live record, so booking context does not disappear between the first search and final checkout.
Guest booking
Desk follow-up
Invoice attached
Right actions, right interface.
Managers, clerks, customers, and company accounts land in focused workspaces instead of a noisy shared admin.
Manager
Rooms, billing, reports.
Clerk
Desk queue and check-in flow.
Customer
Search, book, pay, history.
Company
Corporate stays and billing.
Live availability, not a separate step.
Date filters, guest count, room type, and room state stay visible inside the booking flow.
Date filtersActive
Guest countLive
Room stateAvailable
Walk-ins and check-ins stay in one lane.
Clerks can move from reservation lookup to room assignment, service edits, and checkout without losing the stay record.
Walk-ins
Check-in
Checkout
Room assignDuring check-in
Desk flowFast handoff
Charges stay attached to the stay.
Services, tax, discounts, and invoice totals stay linked to the reservation instead of drifting into side notes.
Service chargesTracked
Invoice stateLinked
Payment pathVisible
System Workflow
How the system flows
Customer flow
1
Search rooms
Choose dates, guests, and room type.
2
Create booking
Reservation and invoice are recorded together.
3
Pay online
Checkout is handled through Stripe.
Clerk flow
1
View reservations
Search, filter, and review booking records.
2
Check in guest
Assign room, confirm arrival, and add services.
3
Checkout
Finalize invoice and update the room status.
Engineering View
How data and edge cases move through the system
Follow the stay record, then surface the risky edge cases.
Every important state change points back to the reservation.
That keeps availability, invoice growth, payment status, and room release understandable even when the stay changes after booking.
Reservation state
Invoice state
Payment state
Room state
01
Reservation created
Guest or company, dates, room choice, and opening status are written once.
02
Invoice grows with the stay
Room rate, services, tax, discounts, and advances stay attached to that same record.
03
Payment state is reconciled
Stripe updates the billing path today, with webhook verification as the next trust layer.
04
Checkout releases the room
Final billing closes the stay and returns room availability for the next reservation.
Double-booking guard
Check room availability before write time and again before staff assignment.
Failed checkout fallback
Abandoned or failed payments should leave the booking pending, not silently confirmed.
Staff-only corrections
Late changes, cancellations, and final billing edits should stay out of customer-facing screens.
Workflow Walkthrough
Role-based workflow walkthrough
Pick a role to open a scrollable set of screens for that workspace.
Database
Data structure
High-level relationship map only.
Reservations stay at the center.
Identity starts the booking, rooms supply availability, invoices collect charges, and payments close the stay.
Accounts start the booking
Users or companies own the stay.
Rooms stay operational
Inventory and room state remain meaningful for staff.
Billing follows the stay
Charges and payments do not drift away from the reservation.
reservations
Guest, room, stay dates, invoice state, and checkout.
People and rooms meet in the stay
Booking ownership and room assignment remain aligned.
Invoices stay attached
Revenue reporting still points back to the same operational record.
Extensions avoid duplication
Company bookings and guest assignment extend the core model instead of splitting it.
Security
Built with protection layers
Security is presented as layered capability instead of a pair of plain cards.
Access, writes, and payment actions are guarded in layers.
QuickStay separates who can act, how state changes are written, and how sensitive payment paths are trusted so risky actions do not depend on one single safeguard.
Session-based authentication
Session timeout, HttpOnly cookies, SameSite cookies, and session regeneration help reduce common session abuse risks after login.
Protected writes and credentials
Passwords are hashed, SQL writes use prepared statements, and CSRF checks help defend sensitive request paths.
Role-scoped operational actions
Billing edits, room assignments, and staff-only corrections are meant to stay inside role-limited workspaces rather than customer views.
Limitations
Current limitations
Solid case-study foundation, a few production gaps remain.
Strong local build, not production hardening yet.
The core workflow works as a case study, but payment trust, guest communication, and secret handling still need stronger delivery infrastructure.
No caching layer
No email pipeline
No verified webhook truth
01
Operations
No email notifications
Guests do not receive automatic confirmations, receipts, or reminder messages yet.
02
Payments
No Stripe webhook verification
Invoice updates should be driven by verified webhook events instead of checkout return flow alone.
03
Security
Hardcoded credentials
Database secrets, API keys, and environment-specific values should move into protected environment variables.
Improvements
What comes next
Planned upgrades to move QuickStay from case study to production-grade.
UX priority
Cleaner responsive admin panels
Improve tables, sidebars, action bars, and dashboard density so clerks can use the system comfortably on tablet and mobile screens without losing important booking context.
Email notifications
Send confirmations, receipts, cancellations, and pre-arrival reminders through a proper mail service.
Verified Stripe webhooks
Update invoice state only after trusted Stripe events arrive on the server rather than relying on the return flow alone.
A stronger case study for
real software engineering.
QuickStay now reads less like a visual mock project and more like an actual system case study: clear stack visibility, explicit workflow ownership, cleaner relationship framing, and honest production limitations.
The next credibility jump is external proof: add a project-specific GitHub repository, a live demo or recorded walkthrough, and exported screens from the running application.