0% found this document useful (0 votes)
35 views70 pages

MERN Booking App Project Overview

Uploaded by

amsharmab22
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
35 views70 pages

MERN Booking App Project Overview

Uploaded by

amsharmab22
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

“MERN Booking App”

Submitted in partial fulfilment of the requirements for the degree of Bachelor of Technology

by

Aditya sharma (221070001)


Haris Ul Islam (221070002)
Aryan Nanda (221070003)

B. Tech. (Computer Engineering) 2022-26

Under the guidance of

Prof. P. M. CHAWAN

Department of Computer Science and Information Technology

Veermata Jijabai Technological Institute

(An Autonomous institute affiliated to the University of

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.

Prof. P. M. Chawan HoD, CE & IT Department

Project Guide

Date: ​

Place: VJTI, MUMBAI

2
TABLE OF CONTENTS

1. PROJECT AND ITS OBJECTIVE


1.1 Project Introduction & Background …………………………………………………………………...6

1.2 Problem Statement ………..……………………………………………………………………………..7

1.3 Core Features of the MERN Booking App ……………………………………………………………..7

1.4 Technical Architecture…………………………………………………………………………………...6

2. PROBLEM ANALYSIS AND PROJECT SCOPING


2.1 Project Scoping and Implementation Strategy …………………………………………………………13

2.2 Functional Requirements Specification ……………………………………………………………..…14

2.3 Out-of-Scope Items …………………………………………………………………………………….15

2.4 Key Deliverables ……………………………………………………………………………………….16

3. PROJECT INITIATION DOCUMENTS


3.1 Business Case …………………………………………………………………………………………..17

3.2 Project Charter …………………………………………………………………………………………22

3.3 Team Contract ………………………………………………………………………………………….23

3.4 Scope Statement ………………………………………………………………………………………..24

4. PROJECT PLANNING DOCUMENTS


4.1 Estimation Document …………………………………………………………………………………..27

4.2 Risk Management Plan ………………………………………………………………………………...31

4.3 Time Management Plan………………………………………………………………………………...33

4.4 Software Quality Assurance (SQA) Plan ………………………………………………………………35

4.5 Software Configuration Management (SCM) Plan …………………………………………………….37

5. PROJECT DESIGN DOCUMENTS

3
5.1 Introduction …………………………………………………………………………………………….38

5.2 Data Modelling – ER Diagrams ………………………………………………………………………..38

5.3 Functional Modelling – DFDs …………………………………………………………………………40

5.4 Behavioural Modelling – State Transition Diagrams ………………………………………………….43

6. DO PRODUCT DESIGN
6.1 Data Design …………………………………………………………………………………………….46

6.2 Architecture Design ……………………………………………………………………………………47

6.3 Module Interface Design ……………………………………………………………………………….49

6.4 User Interface Design ………………………………………………………………………………….51

6.5 Component-Level Design ……………………………………………………………………………...56

7. TRANSFORM ARCHITECTURE DESIGN INTO A MODULAR STRUCTURE


7.1 Frontend Architecture ………………………………………………………………………………….58

7.2 Backend Architecture …………………………………………………………………………………..60

7.3 Transform Algorithms into Code ………………………………………………………………………62

7.4 Test Cases ………………………………………………………………………………………………64

7.5 Code Coverage Test ……………………………………………………………………………………67

7.6 Black Box Testing …………………………………………………………………………………..…68

8. END PROJECT DOCUMENTS


8.1 Milestone Report …………………………………………………………………………………….…71

8.2 Summary of Project Results ……………………………………………………………………………73

9. FINAL REPORTS
9.1 Lessons Learned Report ………………………………………………………………………..………76

9.2 Client Acceptance Form ……………………………………………………………………….………79

10. PROJECT ASSESSMENT


10.1 Why did you do this project? ……………………………………………………………...………….80

4
10.2 What did you produce? ………………………………………………………………….……………80

10.3 Was the project a success? ……………………………………………………………………………81

10.4 What went right on the project? ………………………………………………………...…………….82

10.5 What went wrong on the project? ……………………………………………………….……………82

5
1. PROJECT AND ITS OBJECTIVE

1.1 Project Introduction & Background

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.

1.2 Problem Statement

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:

● Time-consuming manual booking processes.

● 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:

1. User Authentication and Management​


○ User registration and secure login with password encryption. ​
○ Session management using JWT JSON Web Tokens). ​
○ Profile management and secure sign-out. ​
2. Hotel Management (for Owners) ​
○ Add and update hotel listings with details such as price, facilities, and star rating. ​
○ Upload and manage images through cloud storage integration. ​
○ View and manage bookings made by guests. ​
3. Hotel Search and Booking (for Guests) ​
○ Search hotels by city, country, or destination. ​
○ Apply filters such as price, star rating, facilities, and type of accommodation. ​
○ Book hotels with check-in/check-out selection and guest count specification. ​
4. Secure Payment and Booking Records ​
○ Integration with a payment gateway (e.g., Stripe) for safe transactions. ​
○ Automatic booking confirmation after successful payment. ​
○ Guests can view upcoming and past bookings in their account.

1.4 Technical Architecture

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

2.1 Project Scoping and Implementation Strategy

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, AI­powered
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.

2.2Functional Requirements Specification

1. User Authentication & Management

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.​

2. Hotel Management (For Owners)

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.​

3. Hotel Search & Booking (For Guests)

1.​ Guests must be able to search hotels by:


○​ City
○​ Country
○​ Destination
2.​ Guests must be able to apply filters:
○​ Price range
○​ Star rating

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.​

4. Secure Payment Processing

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.

5. Booking Records Management

1.​ Guests must be able to view upcoming bookings.


2.​ Guests must be able to view past bookings.
3.​ Owners must be able to view bookings made on their properties with customer details.
4.​ Each booking must store:
○​ User ID
○​ Hotel ID
○​ Check-in/Check-out dates
○​ Guest count
○​ Payment status
○​ Booking status​

6. System Management & Backend Requirements

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).​

7. User Interface Requirements

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!”​

2.3 Out-of-Scope Items


he following aspects are considered out of scope for the initial phase of the MERN Booking App project:

● 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.

2.4 Key Deliverables

●​ Functional web application for hotel booking and management.


●​ User authentication system with secure login and profile management.
●​ Hotel management module with add/edit hotel functionality and image uploads.
●​ Hotel search and filtering system with results listing and detail pages.
●​ Secure payment integration with Stripe API.
●​ Booking confirmation module with upcoming and past booking records.
●​ Backend API with REST endpoints for users, hotels, and bookings.
●​ Database schema and implementation for storing core data.
●​ Project documentation (including problem statement, scoping, and setup guide). .

13
3. PROJECT INITIATION DOCUMENT

3.1 Business Case

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.

a) Business Case Project Title:

MERN Booking App – Digital Hotel & Accommodation Booking Platform ​


Introduction: The MERN Booking App is an initiative to provide a centralized, user-friendly, and secure
platform for hotel and accommodation booking. It integrates hotel listing management, search and
filtering, secure payments, and booking history into one application. ​
Business Objective: ​
● Streamline hotel booking and management processes. ​
● Provide hotel owners with easy property listing and booking management tools. ​
● Offer users a secure and reliable hotel discovery and booking experience.​

Critical Assumptions & Constraints: ​
● Application must be accessible via modern browsers. ​
● Secure transactions must be ensured via payment gateway integration. ​
● Images must be stored using reliable cloud storage. ​
● Project must be completed within budget and 12 weeks.

14
Analysis of Options: ​

Recommendation: Option 3 – Build MERN Booking App.


Preliminary Requirements:
● User authentication (login, signup, profile).
● Hotel management (listing, editing, image uploads).
● Hotel search and filtering by city, price, facilities.
● Secure booking and payment gateway integration.
● Booking confirmation and history.
Budget Estimate and Financial Analysis
The preliminary budget estimate of the MERN Booking App project is ₹5,20,000.
● 3 Developers for 3 months: ₹3,60,000 (₹40,000/month each).
● Contract UI/UX consultant: ₹40,000.
● Hardware & cloud hosting cost: ₹40,000.
● Software licenses/tools: ₹30,000.
● Testing & Quality Assurance: ₹50,000. Schedule Estimate:
● Duration: 3 months (12 weeks).
● Estimated Payback Period: 1 year.

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.

3.3 Team Contract

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. ​

Team members and roles:

3.4 Scope Statement


The scope statement details the project deliverables and describes the major objectives. The objectives
should include measurable success criteria for the project. ​

Project Title: MERN Booking App ​
Prepared By: Aryan Nanda ​
Date: 25/08/2025​
Project Justification: ​
Testing Database Hotel booking remains fragmented across multiple apps or manual processes. Users face
inefficiency in discovering suitable hotels, while hotel owners struggle with property management and
secure bookings. The MERN Booking App addresses this challenge by providing a unified, scalable, and
secure platform that simplifies the booking process, reduces errors, and improves customer experience.​

Product Characteristics and Requirements Owner Side (Hotel Functionalities): ​
● Add and edit hotel listings. ​
● Upload images via cloud storage. ​
● Manage bookings received. ​
● Update pricing and availability. Guest Side (User Functionalities): ​
● Search hotels by city, price, rating, facilities. ​

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

4.1 Estimation Document

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:

Effort = 686.5 approx 10.5 person-months

Cost Estimate:

21
10.5 PM ₹40,000 = ₹4,20,000

Cost per FP = ~₹6,160



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.

5.2 Data Modelling – ER Diagrams

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

6.1 Data 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.

Core Entities and Schemas

The primary entities in the MindMend data environment include:

1. User

Represents a registered customer or hotel owner.

Fields include:

●​ Name, Email, Password (hashed), Role (Guest / Owner)


●​ Contact Information
●​ Embedded Booking History
●​ Profile Details

2. Hotel

Represents a property listed by a hotel owner.

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

Captures all reservation information.

Fields include:

●​ BookingID
●​ UserID (Guest)
●​ HotelID
●​ CheckIn, CheckOut
●​ GuestCount
●​ PaymentStatus
●​ TotalAmount​

4. Payment

Handles transaction information.

Fields include:

●​ PaymentID
●​ BookingID
●​ Amount
●​ Timestamp
●​ Status (Success / Failed)

5. Image

Metadata for hotel images.

Fields include:

●​ ImageID
●​ URL
●​ HotelID.​

Entity Relationships

Entity Relationships

●​ User (Owner) → manages multiple Hotels


●​ User (Guest) → books → Hotel​

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.

6.2 Architecture Design

The MERN Booking App follows a three-tier client–server architecture, providing scalability, fault
isolation, and clean separation of concerns.

1. Presentation Layer (Client Tier)

This layer delivers all user interfaces for guests and hotel owners:

●​ Hotel search and filtering


●​ Hotel details and pricing
●​ Signup/Login pages
●​ Owner dashboard for managing hotels

32
●​ Booking and payment screens
●​ Viewing upcoming and past bookings​

Technologies used:​
[Link], React Hooks, Context API, Axios, TailwindCSS.

2. Business Logic Layer (Application Server)

The backend handles all core operations:

●​ Secure authentication using JWT


●​ Hotel CRUD operations
●​ Cloudinary image upload and management
●​ Search filtering and pagination logic
●​ Booking creation, conflict checking, and availability validation
●​ Stripe payment integration
●​ Management of user roles and permissions​

Implemented using:​
[Link] + [Link]

3. Data Access Layer (Database Tier)

This layer manages all persisted information:

●​ User accounts and roles


●​ Hotel listings and metadata
●​ Booking records
●​ Payment transactions
●​ Hotel images.

All data is stored in MongoDB Atlas, utilizing flexible NoSQL schemas to support continuous scaling as
the number of hotels and bookings grows.

Guests interact with the system by:

●​ Searching hotels
●​ Selecting dates and occupancy
●​ Completing payments
●​ Accessing booking history​

33
Hotel owners interact by:

●​ Adding/editing hotel listings


●​ Uploading images
●​ Managing availability​

The backend continuously communicates with:

●​ MongoDB (Database)
●​ Stripe API (Payments)
●​ Cloudinary (Image Storage)

6.3 Module Interface Design

This section defines the major functional modules and the interface specifications between frontend and
backend.

6.3.1 Authentication & User Management Module

Function Signature Steps

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.

Login login(email: String, password: 1. Validate credentials. 2. Compare hashed


String) → Token/Error passwords. 3. Generate and return session
token.

6.3.2 Personal Stats Logging Module

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.

ViewProgress viewProgress(userId: ID, type: 1. Retrieve user’s log records. 2. Filter


Enum) → List<Entry> by type. 3. Return entries for graphical
display.

6.3.3 Community Forum Module

Function Signature Steps

CreatePost createPost(userId: ID, content: String, 1. Create post object. 2. Apply


isAnonymous: Bool) → PostID anonymity flag. 3. Store post. 4.
Return PostID.

AddComment addComment(postId: ID, userId: ID, 1. Retrieve post. 2. Add comment


text: String) → Success/Failure object. 3. Save updated document.

6.3.4Payment Module (Stripe Integration)

Function Signature Steps

35
ProcessPaym processPayment(bookingId, Create Stripe Session → Validate payment →
ent amount) → PaymentStatus Update booking → Return status

6.4 User Interface Design

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

●​ Owner Dashboard– Secure authentication with password reset support

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

●​ Booking Page– Interactive form with progress indicators

39
40
6.5 Component-Level Design

This section outlines the internal algorithms for two core features of the MERN Booking App.

6.5.1 Booking Confirmation Component

Algorithm: Handle Booking Creation & Confirmation

Input:​
UserID, HotelID, CheckIn, CheckOut, GuestCount, PaymentInfo

Output:​
Booking Confirmation (BookingID, Hotel Info, Dates, PaymentStatus)

Steps:

1.​ Validate user exists.


2.​ Validate hotel exists.
3.​ Check hotel availability for selected dates.
4.​ If unavailable → return error.
5.​ Create booking with status Pending.
6.​ Send booking details to Payment Module.
7.​ If payment successful:
○​ Update booking status to Confirmed
○​ Return confirmation details
8.​ If payment fails:
○​ Update booking → “Failed”
○​ Return failure message

Error Handling

●​ Invalid User / Hotel


●​ Rooms not available
●​ Stripe failure
●​ Database errors

6.5.2 Secure Payment Processing Component

Algorithm: Process Stripe Payment

41
Input: BookingID, Payment Details​
Output: Payment Status (Success / Failure)

Steps:

1.​ Fetch booking details from database.


2.​ Calculate total payable amount.
3.​ Create Stripe payment session.
4.​ On success:
○​ Update Payment collection
○​ Update booking to Confirmed
5.​ On failure:
○​ Mark booking as Failed
○​ Roll back any temporary holds
6.​ Return payment result to UI.

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.

7.1 Frontend: A Component-Based User Interface

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:

●​ Navbar – Provides navigation links to Home, Search, My Bookings, My Hotels, Login/Signup.​

●​ Footer – Global footer showing support links and copyright.​

●​ HotelCard – Displays hotel name, price, rating, image, and facility icons.​

●​ SearchBar – Input field for location, dates, and occupancy.​

●​ BookingSummaryCard – Shows pricing breakdown during booking.​

●​ FormInput, Button, ImageUploader – Reusable form and utility components.​

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.

Key pages include:

●​ Home – Search interface and featured hotels.​

●​ Login & Signup – User authentication screens.​

●​ SearchResults – Displays hotels matching user filters.​

●​ HotelDetails – Shows hotel description, amenities, availability, and “Book Now” button.​

●​ AddHotel / EditHotel – Property management for hotel owners.​

●​ MyHotels – Dashboard of properties owned by the logged-in user.​

●​ MyBookings – Shows upcoming and past bookings for guests.​

●​ Checkout – Payment UI integrated with Stripe.​

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

●​ AuthContext – Stores authentication state, JWT token, and user info.​

●​ HotelContext – Manages hotel listings for owners.​

●​ BookingContext – Tracks booking steps, user selection, and pricing.​

●​ SearchContext – Stores search results and filter values for global access.​

Custom Hooks

●​ useLogin(), useSignup() – Handle authentication API calls.​

●​ useSearchHotels() – Fetches filtered hotel results.​

●​ useManageHotel() – Adding, editing, and deleting hotel listings.​

●​ useBooking() – Handles booking steps, date validations, and communication with backend.​

●​ usePayment() – Manages Stripe payment processing.​

This prevents prop-drilling and keeps logic centralized and reusable.

45
7.1.4 Routing

Routing is implemented using react-router-dom and defined in [Link].​


Examples:

●​ /login → Login Page​

●​ /register → Signup Page​

●​ /search → SearchResults​

●​ /hotel/:hotelId → Hotel Details Page​

●​ /add-hotel → Add Hotel (Owner Only)​

●​ /my-hotels → Owner Dashboard​

●​ /checkout/:bookingId → Payment Page​

The SPA routing ensures instant navigation without page reloads.

7.2 Backend: A Robust API Foundation

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] – Stores name, email, role (guest/owner), hashed password.​

●​ [Link] – Hotel name, city, country, price, description, rating, images, amenities.​

●​ [Link] – Guest details, stay duration, cost, hotel ref, payment status.​

●​ [Link] – Cloudinary metadata (if stored separately).​

These schemas maintain structured and validated storage in MongoDB.

7.2.2 Controllers

Controller files handle operations and logic tied to incoming requests:

●​ [Link] – Login, registration, JWT token issuing.​

●​ [Link] – CRUD for hotels, image upload handling.​

●​ [Link] – Booking creation, availability check, history retrieval.​

●​ [Link] – Stripe session creation and payment confirmation.​

●​ [Link] – Complex query filtering (price, rating, facilities).​

Business rules are kept cleanly separated from route definitions.

47
7.2.3 Routes

The routes directory maps HTTP endpoints to respective controller functions.

Examples:

●​ POST /api/auth/login → [Link]​

●​ POST /api/hotels → [Link]​

●​ GET /api/search → [Link]​

●​ POST /api/booking/create → [Link]​

●​ POST /api/payment/session → [Link]​

This creates a clear and secure API structure.

7.2.4 Middleware

Backend middleware includes:

●​ [Link] – Validates JWT tokens for protected routes.​

●​ [Link] – Ensures only hotel owners can add/edit properties.​

●​ [Link] – Confirms all required data is present.​

●​ [Link] – Formats and returns server-side errors.​

48
Middleware helps secure the backend and prevent invalid requests.

7.2.5 Server Setup

[Link] initializes:

●​ MongoDB connection​

●​ Global middleware​

●​ API routes​

●​ Environment configuration (dotenv)​

●​ Express server launch​

This acts as the entry point of the backend application.

7.3 Transform Algorithms into Code

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:

1.​ User enters email and password.


2.​ useLogin validates input and triggers a POST request to /api/auth/login.
3.​ Backend checks if the user exists.
4.​ Password is compared with stored hash using bcrypt.
5.​ On mismatch → return error.
6.​ On match → generate JWT containing user ID.
7.​ Backend returns token and user details.
8.​ Frontend stores token in localStorage and updates AuthContext.
9.​ User is redirected to dashboard.

7.3.2 Creating a Booking

Relevant Files:

●​ [Link]​

●​ [Link]​

●​ [Link]

Algorithm Steps:

1.​ User selects metric type (Mood, Sleep, Stress, etc.).


2.​ UI sends POST request to /api/stats/log.
3.​ Backend validates the entry (ranges, types).

50
4.​ New log entry is embedded within UserData document.
5.​ Updated data is saved in MongoDB.
6.​ Frontend updates charts and dashboard.

7.3.3 Payment Processing (Stripe)

Relevant Files:

●​ [Link]
●​ [Link]

Algorithm Steps:

1.​ User submits message.


2.​ Backend retrieves last 5 conversation messages.
3.​ Message is preprocessed and sent to Gemini API.
4.​ AI response is returned.
5.​ User and bot messages are saved in ChatMessage collection.
6.​ Frontend displays the response.

7.4 Test Cases for Important Modules

Below are structured test cases based on the primary modules.

7.4.1 Test Case: User Registration (TC-001)

Objective: Verify successful user registration with valid credentials.

Module: Authentication

Test Type: System

51
Status: Pass

52
53
7.5 Code Coverage Test

Backend testing is performed using Mocha and Chai, covering:

●​ Authentication​

●​ Hotel management CRUD​

●​ Booking creation​

●​ Payment session generation​

●​ Search filtering logic​

Coverage results help identify missing test cases and ensure backend reliability.

7.6 Black Box Testing Using Selenium:


54
55
8. End Project Documents

8.1 Milestone Report

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.

Milestone Date Status Responsible Issue/Comment


(Actual)

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

●​ End-to-End MERN Stack Integration​


Successfully developed and deployed a complete MERN-based booking platform with seamless

57
communication across all modules.​

●​ Secure Authentication System​


Implemented JWT-based login, bcrypt encryption, and secure session management.​

●​ Hotel Owner Dashboard​


Powerful management interface for adding, updating, and deleting hotel listings with Cloudinary
image uploads.​

●​ Advanced Search & Booking Flow​


Implemented real-time availability checks, filters, and a smooth booking workflow.​

●​ Stripe Payment Gateway Integration​


Fully secure online payment system with automatic booking confirmation.​

●​ Robust Testing & QA​


Automated E2E testing and manual UAT ensured strong stability before deployment.

Key Risks Managed

Risk Risk Description Management Strategy & Outcome


ID

R1 Database connectivity MongoDB Atlas backups + retry logic implemented. Risk


failure or data loss mitigated.

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.

8.2 Summary of Project Results

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.

8.2.1 Key Project Achievements

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:

Deliverable Description Outcome

Fully Functional Web Full MERN-based hotel booking Deployed & fully operationa
Application system

User Authentication Secure JWT login + Password Implemented successfully


Module hashing

Property Management Add/update/delete listings with Completed & tested


System images

59
Booking & Payment Stripe/PayPal-powered secure Fully functional
Integration checkout

Admin Dashboard Manage users, listings, bookings Completed

Cloud Deployment AWS deployment + CI/CD pipelines Successful

8.2.2 Business Objectives Achievement

Business Objective Achievement Success Criteria

Simplify hotel booking Achieved Unified platform for exploring, booking, and
process managing stays

Ensure privacy & safety Achieved Encrypted data + JWT authentication + HTTPS

Ensure scalability & Achieved Cloud deployment with load balancing


performance

8.2.3 Financial and Schedule Summary

60
●​ Final Budget: ₹4,80,000 (On Budget)​

●​ Planned Duration: 12 Weeks​

●​ Actual Duration: 12 Weeks​

●​ Financial Outcome: Completed within planned ROI and cost projections

61
9. End Project Documents

9.1 Lessons Learned Report

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.

9.1.1 Project Goal Assessment

Project Name

MERN Booking App – Full-Stack Accommodation Booking Platform

Project Sponsor

ABC Travels Pvt. Ltd.

Project Manager

Aryan Nanda

Project Dates

September 2025 – December 2025

Criteria Target Actual Result Deviation

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).

Time 3 Months (Planned Duration) 3 Months (On None. Schedule


Time) executed as planned.

Cost ₹4,80,000 (Estimated Budget) ₹4,80,000 (Final None. Delivered on


Cost) budget.

9.1.2 Success Criteria Reflection

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.

9.1.3 Main Lessons Learned (Positive & Negative)

Category Lesson Learned Recommendation for Future Projects

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.

Resources / Regular stand-ups, Git-based Maintain Agile sprints, retrospectives,


Team collaboration, and milestone tracking and code reviews for transparency and
increased project efficiency. progress tracking.

Security & Implementing JWT and bcrypt Always adopt a security-by-design


Privacy security early prevented approach rather than retrofitting
vulnerabilities later. authentication.

UI/UX Minor inconsistencies between React Introduce mandatory design review


components and initial Figma designs checkpoints before UI module
required additional refinement. completion.

64
9.2 Client Acceptance Form

Client Name: ABC Travels Pvt. Ltd.

Client Address: VJTI, HR Mahajani Marg, near Five Gardens, Matunga East, Mumbai, Maharashtra,
400019

Project Title: MERN Booking App – Full-Stack Accommodation Booking Platform

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

CLIENT SIGNATURE: ______________________________________

TITLE: _________________________________________________

DATE: _________________________________________________

REMARKS: _______________________________________________

Any further communication or post-deployment queries may be directed to:

Aryan Nanda

65
Project Manager

Email: [Link]@[Link]

66
10. Project Assessment

10.1 Why did you do this project?

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.

10.2 What did you produce?

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.

10.2.1 System Interfaces

●​ 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.

10.2.2 Core Components

●​ 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.

10.2.3 Core Integrations

●​ Secure payment integration using Stripe API to handle transactions safely.​

●​ 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.

10.2.4 Data & Security

●​ A robust MongoDB database storing user accounts, hotel information, and booking records.​

●​ Security measures including hashed passwords, token-based authentication, encrypted


communication, and role-based access control to safeguard user and hotel data.

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.

10.4 What went right on the project?

Several factors contributed to the project’s smooth execution:

●​ 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.

10.5 What went wrong on the project?

Despite the success, the team encountered a few challenges:

●​ 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

You might also like