Ironing WizLaundry Service Management System
A Laravel 12 and React 19 application that runs a laundry business end to end: customers, orders, service workflow, billing, QR-based tracking and reporting.
- Laravel 12
- PHP 8.2
- React 19
- Material UI
- Tailwind CSS
- Vite
- MySQL
- REST APIs
Project snapshot
- Project type
- Laundry Service Management System
- My role
- Full-Stack Developer
- Contribution
- End-to-End Development
- Project context
- Professional Project
Project Overview
Ironing Wiz is a laundry service management system for a laundry and dry-cleaning operation whose daily work — customer records, order tickets, service progress and billing — was handled through manual record-keeping. The application replaces that with a single system: staff register customers, create orders against the services requested, move each order through its stages, and let the system produce the billing instead of writing it up separately.
Its users are the people running the business. Management needs visibility over orders, customers and reporting; operational staff need a short path from a garment arriving to an order record that reflects where that garment is. Every screen is scoped to the role using it.
I built this application end to end as a Full-Stack Developer, as part of my employment at the company that delivered it. The product belongs to that company; what this page documents is the technical implementation I was responsible for.
What stands out
- Role-based dashboards over one customer and order data set
- QR-based order tracking across the service workflow
- Billing derived from the recorded order, with PDF and Excel output
My Role
Full-Stack Developer — End-to-End Development
I handled the complete technical implementation of Ironing Wiz: the MySQL data model, the Laravel 12 backend and its REST API, the React 19 dashboard, the order and billing logic behind them, role-based access, QR-based order tracking, and the PDF and Excel document generation used for invoicing and reporting.
This was a professional project delivered through my employer rather than a product of my own, so the framing here is deliberate: end-to-end technical execution, not ownership of the business.
What I was responsible for
- Relational data model for customers, orders, order items, services and billing in MySQL
- Laravel 12 application and REST API, including validation, authorisation and business rules
- React 19 front-end with Material UI and Tailwind CSS, bundled with Vite
- Role-based dashboards and permission enforcement across the application
- Order lifecycle and status progression logic
- Billing calculated from the recorded order rather than entered by hand
- QR code generation and scan-based order lookup
- Server-side PDF and Excel generation for invoices and business reporting
Services Delivered
The work actually performed on this project, and nothing beyond it.
Full-Stack Development
Backend, front-end, database and the business logic connecting them, delivered as one implementation.
API Development
REST endpoints for customers, orders, status changes, billing and reporting, consumed by the React dashboard.
Database Design
A relational MySQL schema covering customers, orders, order items, services and billing records.
Authentication & Authorisation
Sign-in plus role-based permissions, so each user reaches only the data and actions their role allows.
Business Workflow Development
The order lifecycle itself: intake, service stages, status progression and completion.
Admin Dashboard Development
Management screens for orders, customers and reporting, built as a React application on the same API.
Reporting & Export
PDF documents and Excel exports generated server-side from the same records the dashboard displays.
Data Management
Customer and order history kept in one place instead of spread across notebooks and spreadsheets.
Functionality
How the system works in practice, workflow by workflow.
Customer and order creation
Staff register a customer once and create orders against that record. The order captures the items brought in and the services requested for them, which is what everything downstream — status, billing, reporting — is calculated from.
Order processing
A created order becomes a work item with its own record: what it contains, who it belongs to, and what has to happen to it. Staff work from that record instead of a paper ticket.
Laundry service workflow
Each order moves through the stages the business actually performs on it. Stages are recorded against the order, so the current state of any garment is a question the system can answer.
Order status progression
Status changes are explicit actions handled by the backend rather than free-text notes. Management sees the same status as the staff member who set it, and the order's history shows how it got there.
Billing calculation and automation
Charges are derived from the services recorded on the order, so the bill comes out of the data staff already entered. There is no second pass where someone re-reads a ticket and works out the total by hand.
QR-based order tracking
Orders carry a QR code that resolves to their record. Scanning it identifies the order and its current stage, which is how a physical bag of garments stays matched to the right digital record as it moves.
Management through role-based dashboards
Management and operational staff sign in to different dashboards over the same data. Each role gets the screens its job needs and nothing else, which keeps daily screens usable and keeps administrative data out of general reach.
Reporting and export
Order and billing data can be produced as PDF documents or exported to Excel for use outside the application, generated from current records rather than compiled manually.
Key Features
What the system does, and what each capability is worth to the business running it.
Multi-role dashboard
Separate dashboards per role over one data set, so management screens and operational screens can each be built for the job they serve.
Order management
Every order is a record with its items, services, customer, status and billing attached — the single reference point for that job.
Complete order lifecycle
Intake through service stages to completion, tracked in the system rather than inferred from where a bag is sitting.
Customer management
Customer records with their order history, so repeat customers do not have to be re-entered and past work can be looked up.
Automated billing
Billing generated from the services recorded on the order, removing the separate manual invoicing step.
QR-based tracking
Scannable codes tie a physical order to its record, so identifying an order does not depend on reading a handwritten tag.
PDF generation
Server-side PDF documents for invoices and order paperwork, produced from live records.
Excel export
Order and billing data exported to spreadsheets when the business needs to work with it outside the app.
Role-based access control
Permissions enforced on the server, so what a role can see and change is decided by the backend rather than by which screen was rendered.
Challenges & Approach
The engineering problems this project actually presented, why each was difficult, how it was approached and what changed as a result.
Keeping a multi-stage order lifecycle consistent
- The problem
- An order passes through several stages and is touched by more than one person, while management reads its status at the same time. Without one authoritative record, the status on screen and the state of the actual garments drift apart.
- Why it was difficult
- The difficulty is not storing a status column — it is making sure every path that changes an order goes through the same rules, so no screen or shortcut can leave an order in a state the workflow does not allow.
- Approach
- Status transitions were modelled on the backend and exposed as explicit API actions, so the front-end requests a transition instead of writing arbitrary state. Validation and authorisation sit on those endpoints.
- Outcome
- The dashboard reflects the recorded stage of an order for everyone looking at it, and status history is a by-product of how changes are made rather than something staff have to maintain.
Billing that follows the order instead of a spreadsheet
- The problem
- Charges depend on what was brought in and which services were applied to it. When invoicing is a separate manual step, the bill and the order it came from become two versions of the same fact, and they diverge.
- Why it was difficult
- Laundry pricing is business-specific and applied per item and service, so the logic had to live in the data model rather than in one screen, and it had to stay correct while an order was still being edited.
- Approach
- Billing is computed server-side from the order's recorded services and items, so the invoice is a derivation of the order rather than a parallel document. Generated invoices come from that same computation.
- Outcome
- Billing no longer needs a manual re-entry and reconciliation pass, and an invoice is traceable back to the order lines it was calculated from.
One application, several roles
- The problem
- Management and operational staff need very different views of the same customers and orders. A single set of screens for everyone becomes cluttered for daily use and exposes data that not every user should reach.
- Why it was difficult
- Role separation has to hold in two places at once — the interface a role is given, and the permissions the server enforces — and the two must not fall out of step as features are added.
- Approach
- Roles drive both the dashboard a user lands on and the authorisation checks on the API, with the server treated as the authority. Shared components are reused across dashboards so role-specific screens do not become duplicated code.
- Outcome
- Each role works in a dashboard built for its job, and access is decided by the backend rather than by which front-end route happened to render.
Matching physical garments to digital records
- The problem
- Everything the business handles is physical. If the link between a bag of garments and its order record is a handwritten tag, misreads are inevitable and tend to surface only at collection time.
- Why it was difficult
- The identification step has to be fast enough for staff to use during normal work, and it has to resolve to the right order without anyone typing a reference number.
- Approach
- Orders carry generated QR codes bound to their records. Scanning resolves straight to the order and its current stage, making identification a scan rather than a lookup.
- Outcome
- Order identity travels with the physical items, and staff can confirm which order something belongs to, and where it is in the workflow, at any handover point.
Reports and documents that agree with the application
- The problem
- The business needs invoices and paperwork as PDFs and order data as spreadsheets. Documents assembled by hand from screens are stale the moment they are produced and can contradict the system they came from.
- Why it was difficult
- Document generation carries its own formatting and layout concerns, and it had to be built so that adding a report does not mean reimplementing how the underlying data is queried.
- Approach
- PDF and Excel generation run server-side against the same queries that back the dashboard, so reports and screens read from one source, and export endpoints follow the same API conventions as the rest of the application.
- Outcome
- Reporting is a request rather than an afternoon of copying, and a report cannot disagree with the dashboard it was generated from.
Technologies Used
The stack this project runs on, grouped by the job each part does.
Backend
- Laravel 12
- PHP 8.2
- REST APIs
Front-end
- React 19
- Material UI
- Tailwind CSS
- Vite
Data
- MySQL
Application capabilities
- QR code generation
- PDF generation
- Excel export
Technical Highlights
- End-to-end full-stack implementation across database, API and interface
- Complex, business-specific order and billing workflows
- Role-based application architecture with server-enforced permissions
- REST API consumed by a React 19 dashboard
- Database-driven order management in MySQL
- Automated billing derived from recorded order data
- Server-side PDF and Excel document generation
- QR-based order identification and tracking
Results & Impact
What changed in practice. No figures are quoted here, because none are published for this project.
Manual record-keeping replaced by structured records
Customers, orders and services live in a relational model instead of paper tickets and ad-hoc spreadsheets, so the same order is not written down twice.
Billing produced from order data
The manual invoicing step is gone: charges are derived from what was recorded on the order, which removes the reconciliation work that comes with re-entering figures.
Order visibility for staff and management
Current status is readable from the dashboard, so answering where an order is does not mean asking whoever handled it last.
Centralised business operations
Customers, orders, workflow, billing and reporting are managed from one application rather than several disconnected habits.
Reporting without manual compilation
PDF and Excel output is generated on demand from live records, so reporting is repeatable rather than reassembled each time.