MERN Booking App Project Overview
MERN Booking App Project Overview
Submitted in partial fulfilment of the requirements for the degree of Bachelor of Technology
by
Prof. P. M. CHAWAN
Mumbai) Mumbai-400019
2022-26
CERTIFICATE
This is to certify that Aditya Sharma, Haris Ul Islam and Aryan Nanda, students of B. Tech. Final Year,
Veermata Jijabai Technological Institute (VJTI), Mumbai, completed the SPM Lab Report, entitled
“MERN Booking App” under the guidance of Prof. P. M. Chawan.
Project Guide
Date:
2
TABLE OF CONTENTS
3
5.1 Introduction …………………………………………………………………………………………….38
6. DO PRODUCT DESIGN
6.1 Data Design …………………………………………………………………………………………….46
9. FINAL REPORTS
9.1 Lessons Learned Report ………………………………………………………………………..………76
4
10.2 What did you produce? ………………………………………………………………….……………80
5
1. PROJECT AND ITS OBJECTIVE
The MERN Booking App is a proposed digital platform designed to address the challenges of
accommodation booking and hotel management. Built on the MERN stack MongoDB, [Link], React,
[Link]), the application aims to provide a modern, efficient, and secure system for both guests and hotel
owners.
The vision of this project is to create a centralised booking ecosystem where users can easily search,
compare, and book accommodations, while hotel owners can seamlessly manage their properties. By
integrating cloud storage for hotel images, robust authentication, and secure payment processing, the
platform intends to provide an end-to-end solution that benefits all stakeholders. The inspiration for this
project comes from the widespread reliance on fragmented booking methods and the increasing need for a
secure, accessible, and automated online accommodation management system.
The process of booking accommodations is often fragmented, inefficient, and inconvenient for both users
and hotel owners. Guests face challenges in discovering suitable hotels that match their budget, location,
and facility preferences, while hotel owners struggle with manually managing property details, availability,
and bookings. Traditional methods also lack security and automation, resulting in errors, delays, and risks
during financial transactions. The absence of a centralised and user-friendly platform leads to:
● Difficulty in hotel discovery across different locations. Complexity in property management for hotel
owners.
● Lack of secure and reliable online payment systems. This gap highlights the need for a comprehensive,
digital solution that streamlines both hotel booking and property management processes.
6
1.3 Core Features of the MERN Booking App
The functionality of the MERN Booking App is proposed around four key modules, each contributing to a
complete booking and management experience:
The MERN Booking App will be developed using the MERN stack, combined with third-party services for
payments and file storage:
● MongoDB: NoSQL database to store user accounts, hotel details, and booking records.
● [Link]: Backend framework to implement APIs for authentication, hotel management, and
bookings.
● React: Frontend library for building an interactive and responsive user interface.
● [Link]: Server runtime environment for handling requests and application logic.
● Stripe API: To securely process payments.
● Cloudinary: To store and manage hotel images.
7
Technical Architecture and Technologies
8
2. PROBLEM ANALYSIS AND PROJECT SCOPING
The scope of the MERN Booking App focuses on delivering a complete web-based hotel booking and
management platform for both guests and hotel owners. The project includes the development of core
modules such as user authentication, hotel listing management, hotel search and filtering, secure payment
processing, and booking history tracking. Owners will be able to add and update hotel information, upload
images through cloud storage, and view bookings received, while guests can search for hotels across
locations, apply filters, view detailed pages, and complete bookings through an integrated payment system.
The project scope ensures that all features required for a functional, reliable, and user-friendly booking
platform are included, while intentionally excluding advanced features like dynamic pricing, AIpowered
recommendations, multilingual support, and mobile application development in the initial phase.
The implementation strategy follows a modular and structured approach, beginning with requirement
analysis and system design, followed by backend API development using [Link] and Express, and
frontend interface development using React. MongoDB serves as the primary database for storing users,
hotels, and booking details, while external services such as Cloudinary and Stripe handle media storage
and payment processing. Development will follow an iterative model, ensuring that each module is built,
tested, and integrated progressively. Agile sprints will be used to manage tasks, review progress, resolve
issues early, and refine features based on feedback. The final implementation phase includes end-to-end
testing using Playwright, deployment on a cloud environment, and documentation to ensure the system is
ready for use and future scalability.
1. The system must allow users to register with name, email, password, and role (Guest/Owner).
9
2. The system must allow users to log in securely using encrypted credentials.
3. The system must authenticate users using JWT-based session management.
4. Users must be able to edit and view their profile information.
5. The system must allow users to log out securely.
1. Hotel owners must be able to add new hotels with details:
○ Name
○ Location
○ Country
○ Price per night
○ Facilities
○ Star rating
○ Hotel type
○ Guests allowed
2. Owners must be able to upload multiple hotel images using cloud storage (Cloudinary).
3. Owners must be able to edit hotel information, including pricing and availability.
4. Owners must be able to view all bookings received for their hotels.
10
○ Hotel type
○ Facilities
○ Guest count
3. The system must show hotel details page including images, facilities, description, and pricing.
4. Guests must be able to select check-in/check-out dates and guest count.
5. Guests must be able to book a hotel through a booking interface.
1. The system must integrate Stripe API to process secure credit/debit card payments.
2. Payment must be validated before confirming a booking.
3. After successful payment, the system must generate booking confirmation.
4. Payment failures must trigger booking cancellation or rollback.
11
1. The system must store all data in MongoDB.
2. All CRUD operations (Create, Read, Update, Delete) must be handled through [Link] APIs.
3. The backend must validate all user inputs before database operations.
4. The system must support image upload handling through Cloudinary.
5. The system must send proper API responses for all operations (success/error).
1. The frontend must be built using React with a responsive UI.
2. The system must provide separate interfaces for Guests and Owners.
3. Navigation must include:
○ My Bookings
○ My Hotels
○ Add Hotel
○ Sign In / Sign Out
4. The UI must show notifications like:
○ “Sign in Successful!”
○ “Hotel Saved!”
○ “Registration Success!”
○ “Booking Saved!”
● Flight, Cab, or Travel Package Bookings: The app will initially focus only on hotel and
accommodation booking.
● AIBased Hotel Recommendations: Advanced recommendation systems will not be implemented in the
first phase.
12
● Multilingual Support Initial Release: The platform will initially support only English; future iterations
may include multilingual capabilities.
● Dynamic Pricing Algorithms: Price prediction or demand-based pricing will not be part of the initial
scope.
● Mobile App Development: The first version will be web-only; mobile app development can be
explored later.
13
3. PROJECT INITIATION DOCUMENT
A business case captures the reasoning for initiating a project or task. It is often presented in a
well-structured written document, but may also sometimes come in the form of a short verbal argument or
presentation. The logic of the business case is that, whenever resources such as money or effort are
consumed, they should be in support of a specific business need.
14
Analysis of Options:
15
3.2 Project Charter
It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies
the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority
for the future of the project.
Team Contract is a document prepared by each team prior to starting work on group projects.
Code of Conduct:
● Communicate clearly and meet deadlines. Respect team commitments and share responsibilities.
● Support peers and maintain professionalism.
Participation:
● Weekly meetings (Monday 7 PM).
● Equal contribution expected.
● Transparent reporting of progress.
Communication:
● Slack/WhatsApp for daily updates.
● Google Meet for weekly sync-ups.
● GitHub for code management.
Problem Solving:
● Discuss issues openly in meetings.
● Escalate unresolved conflicts to Project Manager.
Meeting Guidelines:
● Hold regular weekly meetings.
16
● Additional meetings if milestones require.
17
● View detailed hotel pages.
● Book hotels with secure payment.
● Access booking history (upcoming/past).
Summary of Product Deliverables:
● Requirement Specification Document.
● System Design Document.
● Backend API with authentication & booking endpoints.
● Fully Functional Web Application.
● Payment Gateway Integration (Stripe).
● Image Management Integration (Cloudinary).
● Test Plan & Quality Assurance Reports.
● Deployment & Hosting Setup.
● User Manual & Documentation.
18
4. PROJECT PLANNING DOCUMENTS
Theory:
a) Estimation document:
Estimation document includes estimation of cost, time and person.
b) Project risk management is the art and science of identifying, analyzing, and responding to risks
throughout the life of a project and in the best interests of meeting project objectives.
c) Time management is the act or process of planning and exercising conscious control over the amount
of time spent on specific activities, especially to increase effectiveness, efficiency or productivity
d) SQA: Software quality assurance (SQA) consists of a means of monitoring the software engineering
processes and methods used to ensure quality. The SQA plan provides a road map for instituting software
quality assurance.
e) SCM: Supply chain management (SCM) is the management of the flow of goods. It includes the
movement and storage of raw materials, work-in-process inventory, and finished goods from point of
origin to point of consumption.
a) Estimation Document
1. LOC Method Estimation
19
Total Estimated LOC: 5500
● Productivity: 1000 LOC/person-month → Effort = 5.5 person-months
● Team size = 3 → Duration ≈ 2 months
● Labor Rate = ₹40,000/person-month → Total Labor Cost =₹2,20,000
● Cost per LOC ≈ ₹40
2. Function Point (FP) Estimation
● Inputs: 6 × 3 = 18
● Outputs: 5 × 4 = 20
● Files: 4 × 7 = 28
● Interfaces: 3 × 5 = 15 Total Count = 81 FP Influence Factors (ΣFi) = 50 FP = 81 × [0.65 + 0.01 × 50] =
81 × 1.15 ≈ 93.15 FP
● Effort (at 6.5 FP/person-month) = 93.15 / 6.5 ≈ 14.3 person-months
● Team size = 3 → Duration ≈ 4.8 months
● Total Labor Cost = 14.3 × ₹40,000 ≈ ₹5,72,000
● Cost per FP ≈ ₹6,140 3. COCOMO Model Estimation
● Estimated LOC = 5.5 KLOC
● Semi-Detached Mode (moderately complex system)
● Effort = 3 × (5.5)^1.12 ≈ 18.1 PM
● Duration = 2.5 × (18.1)^0.35 ≈ 7.2 months
● Staff ≈ 18.1 / 7.2 ≈ 2.5 people
20
Estimated Budget:
Actual Required Budget: ₹5,50,000 (for slightly
extended timeline & additional QA) b)
Risk Management Plan
FP = 62 [0.65 + 0.01(45)] = 62 1.10 = 68.2 approx 68 FP
Effort Calculation:
Cost Estimate:
21
10.5 PM ₹40,000 = ₹4,20,000
Mitigation Strategies:
● Load balancers & auto-scaling for servers.
● End-to-end encryption and role-based access.
● Weekly sprint reviews to prevent delays.
● Backup payment & image storage options.
● CI/CD for automated testing and integration.
c) Time Management Plan Work Breakdown Structure (WBS):
T1 – Requirement Analysis & System Design
T2 – Detailed Design & Architecture
T3 – Database Implementation (MongoDB + Backend)
T4 – Frontend UI & Dashboard Implementation
T5 – User Authentication & Profile Module
T6 – Hotel Management Module (Listings & Images)
T7 – Hotel Search & Booking Module
T8 – Payment Gateway Integration
T9 – Testing (Unit, Integration, System)
T10 – Integration of Modules
T11 – Bug Fixing & UAT
T12 – Deployment & Final Delivery
Project Duration: 4–5 months (Structured rigor)
22
d) Software Quality Assurance (SQA) Plan
Quality Concepts:
● Continuous monitoring throughout development.
● Agile + CI/CD pipeline to ensure code quality.
● Multi-tiered testing: Unit, Integration, System, Usability.
● Coding standards & GitHub version control.
● Metrics: Response time ≤ 2s, uptime 99%, user satisfaction.
Quality Control Measures:
● Requirement validation → design reviews → code checks → testing → feedback
● Automated tests (Jest, Cypress), Manual testing (UI & usability)
● Defect tracking via Jira/GitHub Issues
Cost of Quality:
● Prevention: Design & code reviews, training, testing tools
23
● Appraisal: Automated/manual test cycles, monitoring
● Failure: Bug fixes, downtime handling
Goal: Deliver a reliable, scalable, secure booking platform with high user satisfaction.
e) SCM Plan
Configuration Identification:
● Source code, UI/UX designs, test cases, deployment scripts, documentation
Configuration Control:
● GitHub with branching strategy (main/dev/feature)
● Pull request review before merging
Configuration Status Accounting:
● Track progress of versions/releases
● Maintain changelog of features & bugs
Configuration Audits:
● Verify builds before deployment
● Ensure files match requirements & documentation
Tools & Roles:
● GitHub, Docker, Jenkins, Jira
● Developers: commits & builds
● QA: validate before release
● PM: approve deployment
24
5. PROJECT DESIGN DOCUMENTS
5.1 Introduction
Theory:
Problem and requirement analysis for the MERN Booking App involves identifying the core needs of users
and hotel owners to ensure a smooth booking experience. It begins with understanding existing challenges
such as scattered hotel information, manual booking processes, lack of secure payments, and difficulty in
managing hotel listings. Functional requirements like user authentication, hotel search, booking flow, and
payment integration are defined, followed by non-functional needs such as security, performance, and
scalability. This analysis helps outline system behavior, data flow, and constraints. It ensures that the final
application is user-centric, efficient, and capable of supporting real-time hotel management and bookings.
Theory:
Data modeling is the process of visually representing how information is structured, stored, and related
within a system. The Entity–Relationship ER Diagram helps design the logical structure of the database.
● Entity: Real-world object about which data is stored (e.g., User, Hotel).
● Attribute: Property of an entity (e.g., UserID, Email).
● Relationship: Association between entities (e.g., User books Hotel).
Entities and Relationships for MERN Booking App:
1. User – Represents guests (customers) or hotel owners.
○ Attributes: UserID, Name, Email, Password, Role Guest/Owner).
2. Hotel – Represents accommodation properties.
○ Attributes: HotelID, Name, Location, Price, Facilities, Rating, OwnerID.
○ Relationship: Each Hotel is managed by one User Owner.
3. Booking – Represents reservation details made by a guest.
25
○ Attributes: BookingID, CheckIn, CheckOut, GuestCount, PaymentStatus.
○ Relationship: Each Booking is made by one User Guest for one Hotel.
4. Payment – Represents secure transactions.
○ Attributes: PaymentID, Amount, Date, Status, BookingID.
○ Relationship: Each Payment is linked to a Booking.
5. Image – Stores hotel images in the cloud.
○ Attributes: ImageID, URL, HotelID.
○ Relationship: Each Hotel can have multiple Images.
Summary Relationships:
● User Owner → manages → Hotel
● User Guest → books → Hotel
● Booking → has → Payment
● Hotel → has → Images
26
b) Functional Modeling: Data Flow Diagrams DFD
Theory
: A Data Flow Diagram DFD shows how data moves between processes, entities, and data stores.
● External Entity: Outside system actors (e.g., User).
● Process: Activities that transform data (e.g., Search Hotels).
● Data Store: Where information is kept (e.g., Database).
● Data Flow: Arrows showing movement of data.
Level 0 Context Diagram Booking System Overview)
● External Entity: User Guest/Owner)
● Process: MERN Booking System
● Data Stores: Hotels, Users, Bookings, Payments
● Flow:
○ Guest → Search/Book Hotels → System
○ Owner → Manage Hotels → System
○ System → Confirm Booking/Payment → Guest
Level 1 Expanded DFD
Main Processes:
1. User Authentication – Signup/Login, Profile Management.
2. Hotel Management Owner – Add/Update Listings, Upload Images.
3. Hotel Search & Booking Guest – Search hotels, Apply filters, Make Booking.
4. Payment Processing – Handle secure payments via Stripe.
5. Booking Records – Store booking history for guest and owner.
27
c) Behavioral Modeling: State Transition Diagram
Theory:
Behavioral modeling explains how the system reacts to user actions over time. A State Transition Diagram
STD is used to model system states and transitions caused by events.
User Session Lifecycle STD for MERN Booking App):
States:
1. Start / Logged Out
2. Authenticated Logged In)
3. Browsing Hotel
4. Booking in Progress
5. Payment Processing
6. Booking Confirmed
7. Logout
Events & Transitions:
● Start → Login Success] → Authenticated
● Authenticated → Search Hotels] → Browsing Hotels
● Browsing Hotels → Select Hotel + Dates] → Booking in Progress
● Booking in Progress → Proceed to Payment] → Payment Processing
● Payment Processing → Success] → Booking Confirmed
● Payment Processing → Failure] → Booking in Progress
28
● Any State → Logout → Logged Out
29
6. DO PRODUCT DESIGN
The data design for the MERN Booking App defines the schema structures used to store user information,
hotel listings, booking records, payment details, and uploaded media.
Since the system uses MongoDB, all data is represented through flexible collections and embedded
documents, allowing scalable and high-performance access for operations such as hotel search, booking
confirmations, and property management.
1. User
Fields include:
2. Hotel
Fields include:
● HotelID, Name
● City, Country
● Description, PricePerNight, StarRating
● Facilities (WiFi, Parking, AC, etc.)
● OwnerID (References User)
● Availability Details
● Embedded Image URLs (stored in Cloudinary)
30
3. Booking
Fields include:
● BookingID
● UserID (Guest)
● HotelID
● CheckIn, CheckOut
● GuestCount
● PaymentStatus
● TotalAmount
4. Payment
Fields include:
● PaymentID
● BookingID
● Amount
● Timestamp
● Status (Success / Failed)
5. Image
Fields include:
● ImageID
● URL
● HotelID.
Entity Relationships
Entity Relationships
31
● Booking → associated with → Payment
● Hotel → contains multiple → Images
Embedding booking history under users and embedding images under hotels ensures fast retrieval, while
high-volume entities such as payments remain independent for scalability.
This data design ensures high performance for hotel search queries, booking workflows, and owner
dashboard operations.
The MERN Booking App follows a three-tier client–server architecture, providing scalability, fault
isolation, and clean separation of concerns.
This layer delivers all user interfaces for guests and hotel owners:
32
● Booking and payment screens
● Viewing upcoming and past bookings
Technologies used:
[Link], React Hooks, Context API, Axios, TailwindCSS.
Implemented using:
[Link] + [Link]
All data is stored in MongoDB Atlas, utilizing flexible NoSQL schemas to support continuous scaling as
the number of hotels and bookings grows.
● Searching hotels
● Selecting dates and occupancy
● Completing payments
● Accessing booking history
33
Hotel owners interact by:
● MongoDB (Database)
● Stripe API (Payments)
● Cloudinary (Image Storage)
This section defines the major functional modules and the interface specifications between frontend and
backend.
Signup signup(name: String, email: String, 1. Validate inputs. 2. Hash password. 3. Create
password: String) → Token/Error User record. 4. Generate and return session
token.
34
Function Signature Steps
LogEntry logEntry(userId: ID, type: Enum, 1. Validate input. 2. Append log entry to
data: Object) → Success/Failure embedded array in user document. 3.
Save updates.
35
ProcessPaym processPayment(bookingId, Create Stripe Session → Validate payment →
ent amount) → PaymentStatus Update booking → Return status
The MERN Booking App features a modern, clean, and intuitive interface for both guests and hotel
owners.
Key UI Screens
● Home Page – Overview of features with links to chatbot, PHQ-9 test, stats log, and resources
36
● Signup Page – Fields for name, email, password, with privacy disclaimers
37
● Hotel Listing Page– Shows mood trends, stress levels, sleep summaries, and PHQ-9 progress
38
● Hotel Details Page – Charts for daily logs and patterns
39
40
6.5 Component-Level Design
This section outlines the internal algorithms for two core features of the MERN Booking App.
Input:
UserID, HotelID, CheckIn, CheckOut, GuestCount, PaymentInfo
Output:
Booking Confirmation (BookingID, Hotel Info, Dates, PaymentStatus)
Steps:
Error Handling
41
Input: BookingID, Payment Details
Output: Payment Status (Success / Failure)
Steps:
Error Handling
● Invalid booking ID
● Stripe timeout or processing failure
● Incorrect card details
42
7. Transform Architecture Design into Modular Structure
This section explains how the high-level architecture of the MERN Booking App was transformed into a
practical modular structure.
The application is divided into two major modules—Frontend Client Application and Backend Server
Application—allowing independent development, scalable enhancement, and smooth deployment. This
modular breakdown supports essential features such as hotel management, property listing, user
authentication, booking workflows, and secure payment integration.
The frontend of the MERN Booking App is implemented as a React single-page application (SPA) using
a component-based architecture. This enables reusability, easy maintenance, and a consistent user
experience across pages.
7.1.1 Components
The src/components directory contains reusable UI components shared across the system. Examples
include:
● HotelCard – Displays hotel name, price, rating, image, and facility icons.
43
Each component is modular, stateless where possible, and acts as a UI building block for various
page-level layouts.
7.1.2 Pages
The src/pages directory contains route-specific, higher-level components that combine reusable elements
with page logic.
● HotelDetails – Shows hotel description, amenities, availability, and “Book Now” button.
Each page interacts with backend APIs to retrieve data, update hotel records, or process bookings.
44
7.1.3 Context and Hooks
Global state management is handled via the React Context API and custom hooks.
Contexts
● SearchContext – Stores search results and filter values for global access.
Custom Hooks
● useBooking() – Handles booking steps, date validations, and communication with backend.
45
7.1.4 Routing
● /search → SearchResults
The backend uses [Link] + [Link] organized using the MVC (Model–View–Controller) pattern.
This separates database models, business logic, and route definitions for better scalability and
maintainability.
7.2.1 Models
46
The models directory includes Mongoose schemas for the Booking App:
● [Link] – Hotel name, city, country, price, description, rating, images, amenities.
● [Link] – Guest details, stay duration, cost, hotel ref, payment status.
7.2.2 Controllers
47
7.2.3 Routes
Examples:
7.2.4 Middleware
48
Middleware helps secure the backend and prevent invalid requests.
[Link] initializes:
● MongoDB connection
● Global middleware
● API routes
This section illustrates how booking logic, authentication, and payments are translated into working code
in the MERN Booking App.
49
7.3.1 User Login
Relevant Files:
● frontend/src/hooks/[Link]
● backend/controllers/[Link]
Algorithm Workflow:
Relevant Files:
● [Link]
● [Link]
● [Link]
Algorithm Steps:
50
4. New log entry is embedded within UserData document.
5. Updated data is saved in MongoDB.
6. Frontend updates charts and dashboard.
Relevant Files:
● [Link]
● [Link]
Algorithm Steps:
Module: Authentication
51
Status: Pass
52
53
7.5 Code Coverage Test
● Authentication
● Booking creation
Coverage results help identify missing test cases and ensure backend reliability.
54
55
8. End Project Documents
The MERN Booking App – Hotel Reservation and Management System project was executed within a
structured 12-week development cycle (September 1, 2025 – December 1, 2025).
All major milestones were completed on time, and the system achieved full operational readiness by the
planned release date.
The table below summarizes each finalized milestone, its completion status, and relevant comments.
Project Initiation Sept 1, Completed Aryan Nanda Business Case, Project Charter, and
Documents 2025 (PM) Scope Statement approved on
Approved schedule.
System Design & Sept 14, Completed System Full-stack architecture, MongoDB
Architecture 2025 Design Team schemas, and UI/UX wireframes
Finalized completed ahead of schedule.
Core Framework & Sept 29, Completed Development MERN stack initialized; JWT
Authentication 2025 Team authentication and bcrypt hashing
Functional implemented.
56
Hotel Management Oct 16, Completed Backend + CRUD operations for hotels with
Module Functional 2025 Frontend Cloudinary image storage
Teams completed.
Search & Filtering Nov 2, Completed Full Stack Integration required additional
Module Functional 2025 Team testing for crisis detection logic.
Anonymous Nov 15, Completed Full Stack Location-based search with price,
Community Forum 2025 Team rating, and facility filters
Functional implemented successfully.
Booking & Payment Nov 21, Completed Backend Stripe integrated; booking
Integration 2025 Team confirmation logic tested without
issues.
Testing & Quality Nov 29, Completed QA Team Unit, integration, and end-to-end
Assurance (QA) 2025 testing completed using Postman &
Playwright.
Final Release & Dec 1, Completed Entire Team User guides, API documentation,
Production 2025 and final presentation delivered.
Deployment
Major Accomplishments
57
communication across all modules.
R2 Payment gateway Used Stripe sandbox extensively; all flows validated. Risk
issues mitigated.
58
R3 Authentication Implemented bcrypt hashing, JWT verification, HTTPS. Risk
vulnerabilities mitigated.
The MERN Booking App project has been successfully completed, delivering a scalable, secure, and
intuitive accommodation booking and management platform. All objectives defined in the Scope
Statement and Business Case were met.
MindMend introduces a unified digital ecosystem that supports mental wellness through assessments,
AI-based guidance, community interaction, and personalized data tracking. The project successfully
delivered:
Fully Functional Web Full MERN-based hotel booking Deployed & fully operationa
Application system
59
Booking & Payment Stripe/PayPal-powered secure Fully functional
Integration checkout
Simplify hotel booking Achieved Unified platform for exploring, booking, and
process managing stays
Ensure privacy & safety Achieved Encrypted data + JWT authentication + HTTPS
60
● Final Budget: ₹4,80,000 (On Budget)
61
9. End Project Documents
A comprehensive review of the MERN Booking App project highlights the major insights, successes, and
recommendations gathered throughout development and deployment. This report is archived for future
reference and continuous process improvement.
Project Name
Project Sponsor
Project Manager
Aryan Nanda
Project Dates
Scope Deliver complete functional modules 100% of core None. All out-of-scope
(Authentication, Hotel Management, functional modules items were
62
Hotel Search, Booking, Payments, delivered. maintained.
Deployment).
The MERN Booking App successfully met all defined success criteria.
The system provided a seamless booking experience with secure authentication, hotel search, booking
workflows, and payment integration. All components were delivered within schedule and budget.
A key success factor was the early setup of backend architecture, which allowed stable API integration
with React components. Another major contributor was the timely integration of Stripe payment
gateway, enabling thorough sandbox testing before deployment.
Adherence to project documentation and milestone planning ensured smooth execution, prevented scope
creep, and maintained clarity among team members throughout development.
63
Schedule & Payment gateway integration required Begin sandbox API testing earlier to
Time additional debugging time due to avoid last-minute integration delays.
asynchronous handling.
Technical / Early setup of [Link] and Prioritize backend models and endpoints
AI MongoDB ensured smooth early to avoid data flow inconsistencies.
integration with frontend modules.
64
9.2 Client Acceptance Form
Client Address: VJTI, HR Mahajani Marg, near Five Gardens, Matunga East, Mumbai, Maharashtra,
400019
This document certifies that the MERN Booking App project has been thoroughly reviewed by the client,
and all deliverables as outlined in the approved Scope Statement have been successfully completed.
All functionalities—including secure authentication, hotel listing management, hotel search, booking
workflow, Stripe payment integration, and AWS deployment—have passed final QA and UAT. The
application has been deployed in the client’s production environment.
The client acknowledges that the development team will provide 6 months of post-deployment support
and bug-fix warranty.
Any future enhancements, feature extensions, or design changes will require a new agreement.
Client Acceptance
TITLE: _________________________________________________
DATE: _________________________________________________
REMARKS: _______________________________________________
Aryan Nanda
65
Project Manager
Email: [Link]@[Link]
66
10. Project Assessment
This project was initiated to overcome the inefficiencies and fragmentation in the accommodation booking
process. Users often face difficulties in identifying suitable hotels that match their budget, preferred
location, and required amenities, while hotel owners struggle with manually managing listings, availability,
images, and bookings. The lack of a unified platform also leads to delays, errors, and security concerns,
especially during payment processing.
To address these gaps, the goal of the MERN Booking App was to design a centralized, digital,
user-friendly system that automates both hotel discovery and property management. By integrating hotel
search, hotel listing management, secure authentication, booking workflows, image storage, and safe
online payments, the project aimed to create an end-to-end solution that benefits both guests and hotel
owners. Ultimately, the intention was to convert the traditional manual process into a seamless, modern,
and automated booking ecosystem.
The team developed a fully-functional accommodation booking platform using the MERN stack, offering
an intuitive interface for users and a powerful management console for hotel owners. The system integrates
secure authentication, hotel listing tools, advanced search and filtering, and online payment support.
● A responsive web interface built using React to ensure smooth navigation on all devices.
● A Guest Dashboard displaying upcoming/past bookings, profile information, and payment history.
● A Hotel Owner Panel allowing property owners to add, update, and manage hotel listings, images,
67
and bookings.
● A complete Authentication Module using JWT for secure login, registration, and session handling.
● A Hotel Management Module allowing hotel owners to upload images (via Cloudinary), specify
hotel details, and track reservations.
● A Search & Booking Engine enabling users to find hotels by city or country, apply filters, and
complete bookings.
● Cloud-based image storage using Cloudinary for optimized hotel image management.
● A structured API layer built with [Link] supporting smooth communication between frontend
and backend.
● A robust MongoDB database storing user accounts, hotel information, and booking records.
68
10.3 Was the project a success?
Yes, the project was successful and met all major objectives.
All essential modules—authentication, hotel management, search and booking functionality, payment
integration, and image storage—were implemented and rigorously tested. The application demonstrated
stable performance, fast search capabilities, and smooth interaction between modules.
The Stripe integration, considered the most critical component, worked reliably across test cases,
confirming the platform’s ability to support secure financial transactions. User tests further validated that
the system significantly improved the convenience and efficiency of both booking and property
management processes.
● Seamless coordination between frontend and backend teams enabled rapid development and
integration.
● Early implementation of the payment and cloud storage modules reduced technical risks during
later stages.
● MongoDB’s flexible schema design proved ideal for managing hotels, bookings, and user accounts
efficiently.
● The UI/UX design focused on simplicity, reducing friction for both users and hotel owners.
● Agile development cycles and continuous communication helped the team stay aligned with the
timeline.
69
● The testing phase showed strong reliability across modules, validating the architectural decisions of
the MERN stack.
● Integrating payment systems required additional testing time to ensure error-free and secure
transactions.
● Cloud service usage (Cloudinary and Stripe) resulted in slightly higher operational costs than
expected.
● Advanced features such as multilingual support, admin analytics, and dynamic pricing had to be
postponed due to time constraints.
● Initial versions of the property management module required redesigning to better suit owner
workflows.
These obstacles were managed effectively and did not affect the delivery of core features.
70