Web Development Course Project 2026-03-25

StitchMart

E-commerce website for embroidery businesses.

ReactExpress.jsMongoDBRedux Toolkit

Project Overview

Building a course-scale operations portal for embroidery businesses across bookings, customers, payments, notifications, and staff-facing workflows.

StitchMart was built as a group assignment for a web development course. The repository is split into a Create React App frontend and an Express/MongoDB backend, with the team aiming to cover both customer-facing flows and internal business operations in a single app.

Role Full-stack contributor working across the React frontend, Express APIs, and the wiring between multi-module business flows.
Timeline Ongoing
Team / Collaboration Student group assignment for a web development course

Key Highlights

Project type
Group assignment for a web development course
Frontend stack
React, React Router, Redux Toolkit, redux-persist
Backend scope
Auth, bookings, appointments, clients, orders, payments, notifications
Integrations
Firebase uploads, Nodemailer email endpoints, EmailJS

The Challenges

  • The project needed to demonstrate more than a single CRUD screen, so the team had to connect user auth, bookings, appointments, customer records, notifications, payments, and supporting admin views into one coherent system.
  • Embroidery businesses have both customer-facing and operator-facing needs, which means routing, state, and data models must work across very different screens.
  • With course-level time constraints, the challenge was deciding which flows should be fully API-backed and which could remain prototype-style interfaces.

Project Goals

  • Deliver a working full-stack group project with multiple related business modules instead of an isolated feature demo.
  • Split responsibilities cleanly between a React client and Express/MongoDB backend so the team could collaborate across frontend and backend scopes.
  • Use a familiar stack that still covers protected routes, persisted session state, CRUD operations, and a few real integrations.

System Architecture

Component 01
ReactReact RouterCreate React App

React frontend

The frontend is a Create React App project using React Router to cover public marketing pages, login and signup, profile management, bookings, tutorials, notifications, finance, products, and inventory views from one client codebase.

Component 02
Redux Toolkitredux-persistJWT

Session and protected flows

Protected views are wired through a private-route pattern on the client, while Redux Toolkit plus redux-persist keeps user session state available across screens. On the backend, JWT verification is handled through cookies for authenticated requests.

Component 03
Express.jsNode.jsMongoDBMongoose

Express API layer

The backend exposes route groups for auth, users, appointments, bookings, clients, orders, payments, and notifications, with Mongoose models backing the main business entities and CRUD-heavy flows.

Component 04
FirebaseNodemailerEmailJS

Supporting integrations

The project uses Firebase Storage for profile image uploads and includes email-sending paths via Nodemailer and EmailJS, which gave the team a way to show practical integration work beyond basic forms and tables.

Technology Rationale

React + React Router
A practical choice for a course project with many screens because it let the team separate public pages, protected pages, and workflow-specific modules without introducing extra routing complexity.
Express.js + Mongoose
Useful for quickly standing up multiple CRUD APIs across bookings, clients, orders, payments, and notifications while the domain model was still being shaped.
Redux Toolkit + redux-persist
Helped keep authenticated user state available across many screens and avoided pushing shared session concerns down through props.
Firebase Storage
Gave the project a straightforward way to handle profile image uploads without building a separate storage pipeline during the course timeline.
Bootstrap + React-Bootstrap
Supported faster UI delivery for a student team where the main challenge was integrating many workflows rather than inventing a custom design system.

Tradeoffs & Constraints

Breadth vs. polish

Covering bookings, appointments, notifications, payments, inventory, and finance made the project feel like a real operations app, but it also meant not every module could receive the same product depth.

Persistent flows vs. prototype screens

Several flows are clearly API-backed, while some screens such as inventory and parts of the finance area behave more like static or demo-style interfaces. That split is reasonable for a course project, but it is important to represent it honestly.

Course delivery vs. production hardening

The repo favors getting the end-to-end experience working over hardening concerns such as secret handling, configuration rigor, and automated tests, which is typical for assignment timelines.

Lessons Learned

  • Group projects benefit from clear module ownership and naming conventions early, especially once frontend and backend work start moving in parallel.
  • Shared auth and session patterns matter a lot when one app contains both public pages and many protected business flows.
  • CRUD-heavy business apps expose data-consistency issues quickly, especially around IDs and relationships between clients, orders, and payments.
  • It helps to distinguish prototype modules from persistent modules explicitly so the product story stays honest and maintainable.

Outcomes & Next Steps

The result is a credible full-stack course project that demonstrates breadth: JWT cookie auth, persisted Redux user state, MongoDB-backed bookings and business records, and supporting modules for finance, inventory, tutorials, and notifications. It is strongest as a multi-module integration project rather than a production-hardened SaaS build.

  • Replace static inventory and finance views with API-backed persistence and reporting flows.
Back to all projects