Project Overview
This project is a business operations platform for a dry cleaning and laundry service. It supports the people who run the operation day to day: front-desk staff creating orders, internal teams processing garments through different departments, logistics staff coordinating pickups and deliveries, drivers completing routes, finance and admin users reconciling payments, and support staff handling exceptions.
The reason a system like this exists is simple: once a service business grows beyond a small manual workflow, disconnected tools start creating friction everywhere. Orders, garments, pickups, pricing, payments, delivery promises, client communication, and operational accountability all need to stay aligned. This platform brings those moving parts into one place.
Quick Summary
- Project Type: Internal operations, logistics, and commerce platform
- Platform: Web-based admin console with a mobile-oriented route workflow
- My Role: Developer, from scratch to delivery, with continued post-launch maintenance
- Team Size: N/A
- Duration: N/A
Problem
The business challenge was not just managing orders. It was managing the full operational chain behind each order.
A dry cleaning order can turn into dozens of state changes and handoffs: customer intake, pricing, tagging, department-specific processing, packing, storage, collection or delivery scheduling, route execution, payment collection, refunds, notifications, and support follow-up. If those steps live in separate tools or informal processes, teams lose visibility and exceptions become expensive to manage.
The system required the existing operational reality required:
- customer and billing records that could support both retail and account-style workflows
- item-level tracking rather than order-level-only tracking
- support for pickups, deliveries, and outlet collection
- configurable fees, discounts, tax treatment, and exemptions
- internal messaging, activity logs, and support tickets for exception handling
- operational tooling for routes, stops, drivers, vehicles, and staging locations
This was the kind of problem where the software had to reflect how the business actually runs, not how a generic ecommerce system assumes it runs.
Goal
Success looked like having one system that could coordinate the business from intake through fulfillment and payment, while still leaving room for operational nuance.
In practical terms, that meant:
- centralizing orders, clients, payments, and logistics in a single platform
- making internal workflows traceable at item, batch, pack, and trip level
- reducing the friction between office staff, operations staff, and drivers
- supporting configurable business rules instead of hardcoding every variation
- building something maintainable enough to continue evolving after delivery
My Contribution
I built this project end to end, from greenfield implementation through delivery, and then stayed involved for ongoing maintenance once the application was live.
My role covered both backend and frontend responsibilities. On the backend, I shaped the domain model, API structure, workflow state transitions, integrations, notifications, reporting endpoints, and deployment setup. On the frontend, I helped build a large Vue-based console that organizes the system around real operational modules rather than a flat CRUD interface.
What stood out in this project is that it required product thinking as much as engineering. A lot of the work was not just "build a screen" or "add an endpoint." It was deciding how to represent real-world workflow states in software, how to keep financial and operational data consistent, and how to make the system usable by different roles with different needs.
Because I also stayed with the product after launch, I had to design for change. That usually leads to better engineering decisions than building only for first delivery.
Tech Stack
Frontend
- Vue 3 Used to build a large single-page operations console with modular route-based sections.
- TypeScript Important here because the app spans many domains and data contracts, so stronger typing helps keep complexity manageable.
- Pinia Used for client-side state management across the console.
- Vue Router Used to structure the product around distinct operational areas such as orders, clients, logistics, settings, support, and reports.
- PrimeVue Provided a UI foundation for forms, tables, dialogs, menus, and high-density admin interactions.
- Tailwind CSS Used for fast layout and consistent styling across a large set of operational screens.
- Tiptap Used for rich-text customization flows, especially around printable slip templates and customer-facing document content.
- Ably client Supports real-time updates for operational views where stale data would be a problem.
- QZ Tray integration Enabled signed local printing, which is a practical requirement in service operations.
Backend
- Laravel 11 A good fit for quickly building a large domain-driven business application with queues, notifications, validation, and a strong testing story.
- Laravel Sanctum Used for token-based console authentication.
- PHP 8.2+ Used across the backend domain and API layer.
- PostgreSQL Strong relational fit for a system with many interconnected business entities.
- PostGIS via Magellan Used where geospatial logic mattered, especially route and service-area matching.
- Queued jobs Used for work such as route optimization, which is better handled asynchronously than inline in the request cycle.
Infrastructure
- AWS Lambda via Bref The backend is deployed serverlessly, reflecting an emphasis on lean operations and scalable request handling.
- Serverless Framework Used to define application functions, schedules, VPC settings, and queue workers.
- S3-compatible storage Used for attachments and upload flows.
- DynamoDB cache table Used as part of the deployed serverless footprint.
- Sentry Used for production exception tracking.
Integrations
- Google route optimization services Used to optimize trip sequencing for pickup and delivery workflows.
- External payment provider webhook Used to capture and reconcile payment activity back into orders.
- WhatsApp integration Used for template-based customer communication.
- Email notifications Used for operational and customer-facing messaging.
- Ably Used for real-time token issuance and live event delivery.
- QZ Tray certificate signing Used to securely support local receipt or slip printing.
Testing
- PHPUnit Used across a broad backend test suite.
- Domain-focused API and lifecycle tests The tests cover CRUD flows, searches, listings, lifecycle behavior, route optimization, payments, reporting, integrations, and operational edge cases.
Architecture Notes
The application is organized as a split frontend and backend project, which is a sensible choice for a system of this size. The backend follows a domain-oriented structure rather than a purely technical layer structure. That is one of the strongest architectural decisions in the codebase.
Instead of putting everything into generic controllers and models, the backend is broken into domains such as orders, items, trips, stops, clients, payments, pickup requests, routes, locations, integrations, reports, and tickets. That makes the system easier to reason about because the code is grouped around business concepts.
Some maintainability decisions that stand out:
- item, order, batch, pack, stop, and trip are separate concepts, which avoids collapsing the operational model into a few overloaded tables
- observers are used to keep domain side effects and state synchronization together
- searchable fields and trigram indexes show attention to performance in large operational lists
- queues are used where work is expensive or slow, such as route optimization
- the frontend mirrors the business structure, which helps keep the UI aligned with how teams actually work
From a scalability perspective, the codebase makes a few important choices:
- stateless API authentication fits well with a distributed frontend and serverless backend
- serverless deployment reduces always-on infrastructure overhead
- background jobs prevent optimization work from blocking user requests
- geospatial routing logic is separated into dedicated services and jobs
- the large set of list, paginate, search, and export endpoints shows the product was designed for real operational volume rather than toy datasets
What I Built
Order and Customer Operations Core
Purpose
The core of the platform is the relationship between clients, orders, payments, discounts, taxes, gift cards, and billing rules.
Engineering challenges
One challenge here is that service businesses do not behave like straightforward carts and checkouts. Pricing can depend on item type, quantity, discounts, promo codes, taxes, minimum order rules, delivery fees, storage fees, and account-specific exceptions.
Implementation highlights
The domain model captures those concerns directly in the order and client layers. Orders calculate totals, discounts, promo code effects, tax, balance, and payment state. Clients carry billing details, credit terms, tax overrides, fee exemptions, and notification preferences.
Business value
This gives the business a reliable operational and financial source of truth instead of scattering that logic across manual steps or disconnected tools.
Item-Level Production Workflow
Purpose
This module tracks how garments move through the production process.
Engineering challenges
A single order can contain many items, and each item may follow a different path. Some garments need spotting, some need pressing, some need mending, and all of them need to move cleanly through tagging, cleaning, inspection, packing, and staging.
Implementation highlights
The item model stores granular workflow markers like tagged_at, cleaned_at, pressed_at, mended_at, spotted_at, inspected_at, marked_for_packing_at, and packed_at. That is a strong design choice because it preserves operational truth without forcing everything into one generic status field.
Business value
Item-level visibility matters in a service operation because customers, staff, and drivers all feel the cost of ambiguity. This design supports clearer handoffs and fewer blind spots.
Packaging, Fulfillment, and Delivery Coordination
Purpose
Orders are turned into batches and packs that can then be prepared for outlet collection or address-based delivery.
Engineering challenges
The challenge here is modeling fulfillment in a way that works for both operational preparation and final handoff. It is not enough to know an order exists; the system has to know what is packed, where it is going, when it is due, and whether it is actually ready.
Implementation highlights
The batch model computes fulfillment-oriented statuses such as pending items, ready for delivery, out for delivery, ready for collection, and delivered. It also supports destination types and deadline logic tied to location settings.
Business value
This turns fulfillment into a first-class workflow rather than an afterthought, which is important for service quality and internal coordination.
Pickup and Route Management
Purpose
This module covers pickup requests, trips, route slots, stops, vehicles, drivers, service areas, and route optimization.
Engineering challenges
Logistics workflows are usually where operational software becomes much more demanding. Scheduling must respect geography, timing windows, route capacity, and the difference between pickups and deliveries. On top of that, the business still needs a usable interface for dispatch and drivers.
Implementation highlights
The system models route areas, route slots, trips, and stops as separate concepts. It uses geospatial matching to associate addresses with service areas, and it sends trip optimization work to a queue-backed job that calls an external route optimization service. The frontend also includes a mobile-oriented "My Route" workflow for drivers to navigate stops, mark completion or failure, collect payment, and even create draft orders directly from pickup activity.
Business value
This closes the loop between planning and execution. Dispatchers can structure work, and drivers can complete real-world tasks without falling back to paper or side channels.
Payments, Refunds, and Financial Reporting
Purpose
This part of the system manages payment capture, reconciliation, refunds, balances, and reporting.
Engineering challenges
Financial workflows are unforgiving. The system has to track partial payments, gift card payments, refunds, settlement activity, and account balances while keeping the order state understandable to operational users.
Implementation highlights
The code includes dedicated payment, refund, settlement, and balance domains, along with reporting endpoints like X and Z reports. There is also a payment webhook flow that safely attaches provider callbacks to orders.
Business value
This reduces the gap between what operations thinks happened and what finance can actually reconcile.
Notifications, Printing, and Client Communication
Purpose
This module supports communication and document output around the operational flow.
Engineering challenges
Operational communication is rarely just email. Businesses often need different channels, templated messages, printable receipts, internal slips, and secure local printing.
Implementation highlights
The platform includes notification templates, email notifications, WhatsApp template delivery, customizable slip content, QR code-based print previews, and certificate-backed signing for local print jobs through QZ Tray.
Business value
This helps the product function as an actual operational hub, not just a database with forms.
Admin, Settings, and Internal Control Surfaces
Purpose
The system includes a large set of administrative modules for maintaining the business itself.
Engineering challenges
The hard part with internal systems is often avoiding hardcoded business rules that become expensive later. Pricing, tax, damage catalogs, lead times, logistics fees, user roles, integrations, templates, and location settings all need to be adjustable.
Implementation highlights
The console has dedicated sections for discounts, tax rates, credit terms, storage fees, damages, delivery and pickup fees, drivers, vehicles, routes, locations, user management, integrations, and document customization.
Business value
This lowers the long-term cost of change because operational teams can adjust system behavior without constantly needing code changes.
Key Engineering Challenges
Workflow complexity across multiple business roles
This project had to serve front-desk staff, operations teams, drivers, finance users, and support users. Each group sees the same business differently. I found the interesting part was creating a data model that could support those perspectives without duplicating logic everywhere.
Representing real-world state without oversimplifying it
A generic single-status model would have been easier to build, but it would not have matched the actual operation. Modeling item, batch, stop, trip, and payment state separately created more work up front, but it was the right tradeoff for clarity and long-term flexibility.
Keeping operational and financial truth aligned
Orders are not complete just because they exist, and payments are not simple just because a total exists. The platform had to deal with balances, refunds, delivery payment collection, payment links, and provider callbacks while still keeping the user experience understandable.
Building logistics capability into a service business platform
Adding route planning and stop execution significantly increases system complexity. It introduces geospatial data, scheduling, asynchronous optimization, mobile execution, and failure handling. The codebase shows a deliberate attempt to model those concerns explicitly instead of burying them in ad hoc logic.
Designing for configurability after launch
Because I continued maintaining the product after delivery, the system needed to accommodate real change. The extensive settings, integrations, templates, and admin modules suggest the architecture was shaped with that reality in mind.
Outcome
The platform became a unified system for running a dry cleaning and laundry operation across customer management, production workflow, fulfillment, logistics, payments, reporting, and administration.
In this project, I can reasonably say it consolidated workflows that are often fragmented across spreadsheets, messaging apps, generic invoicing tools, and manual coordination. The result is a more coherent operating model: staff can see the same order from different viewpoints, drivers can work from route-aware mobile flows, and administrative users can adjust business rules through the console.
Verification was focused on end-to-end user flows, regression checks, and manual staging validation. What the code does show clearly is that this product was built to support real operational usage rather than a narrow prototype.
Why This Project Matters
This is an important project in my portfolio because it shows the kind of work I enjoy most: software that sits close to the business and has to solve real operational problems, not just present data nicely.
I like this project because it demonstrates breadth and depth at the same time. There is backend architecture, frontend application structure, workflow design, geospatial logistics, payments, notifications, reporting, deployment, and post-launch maintainability. It also reflects ownership. I was not only implementing tickets inside a small slice of the stack. I was shaping how the system worked from the ground up and then staying with it as the real-world needs evolved.
For me, that combination of system design, business understanding, and long-term responsibility is what makes the project portfolio-worthy.
What I Learned
This project reinforced that operational software becomes valuable when it respects how work actually happens.
One thing it taught me is that modeling the business honestly is usually worth the extra effort. Separating orders, items, packs, batches, trips, and stops may look more complex at first, but it creates room for the product to grow without turning into a tangle of exceptions.
It also deepened my appreciation for post-launch engineering. Building from scratch is one skill. Maintaining and extending a live operational system is another. You start thinking more carefully about defaults, migrations, observability, configurability, and how small decisions affect the people using the system every day.
I enjoyed working on this because it sits at the intersection of architecture, product thinking, and execution. It is the kind of project that makes you better not only at writing code, but at understanding how software supports a business in practice.