The product
This is a custom cloud operations platform for a Toronto moving company, running on the MoverWise platform brand. It covers the whole business in one tool: lead capture, automated quoting, dispatch, crew and truck management, Bills of Lading, invoicing, claims, payroll, and warehouse logistics, across branches in nearly every province in Canada. It replaced manual, fragmented systems with a single platform a brand-new employee can run on day one.
My role
I am the technology partner behind it, with full ownership of architecture, development, hosting, and roadmap from day one. What makes this engagement matter is how it started: a single $600 website project on Upwork back in 2011 that grew into a 15-year technology partnership, my longest-running client relationship. That is the kind of trust a hiring founder is really asking about when they ask for references.
Architecture
The platform runs on PHP with a deliberately layered, domain-driven design that has stayed maintainable across 15 years of feature growth:
- Layered separation of concerns. Page controllers handle the request, domain service classes hold the business logic, a shared data-access layer talks to the database, and template files render the view. Logic does not leak between layers, which is why a fifteen-year-old codebase is still safe to extend.
- A single data-access contract, reused everywhere. Every domain class (estimates, customers, drivers, trucks, containers, manifests, staff, leads, inventory) inherits one data-access base that exposes a consistent create, read, update, and toggle-state interface over PDO. New entities get full persistence by extending the base instead of rewriting query plumbing. That is dependency inversion and DRY doing real work.
- Parameterized everything. Reads and writes run through prepared statements with bound parameters, so user input never reaches SQL as a string. Security is a property of the data layer, not something sprinkled on per page.
- A modular pricing engine. Quoting is built from independent surcharge modules, one per cost type: ferry, labour, packing materials, packing services, piano handling, storage and warehousing, fixed fees, and ad-hoc charges. Pricing rules for a new charge type are added as a module, not by editing the core estimator. That is the Open/Closed Principle in practice.
- Estimate as the domain aggregate. A move flows through one cohesive lifecycle: lead becomes estimate becomes job becomes invoice, with claims, worksheets, warehouse storage, list of goods, and calendar events all hanging off the same record. Modeling the business as one connected aggregate is what lets a dispatcher see a job end to end.
- Role-based access by privilege tier. Admin, supervisor, staff, and driver each get a scoped surface, with the super-admin tier separated out entirely, so a brand-new crew member and an owner see different, appropriately limited views of the same system.
The engineering challenge
A moving company is a logistics business with a sales funnel, a fleet, a warehouse, and a payroll bolted on. Modeling all of that in one system, while keeping it simple enough for non-technical dispatchers and crews to run day to day, is the core challenge. Long-distance, local, cross-border, and multi-leg moves each need different dispatch logic and different pricing, and every job has to generate accurate Bills of Lading, invoices, and tax handling across provinces. The work is holding that complexity behind an interface a novice can operate, and keeping it correct as the business changes year over year.
What I built
- Centralized management across 25+ branches in all provinces
- A complete CRM tracking leads, estimates, jobs, invoices, payments, and communications
- A lead-capture endpoint that ingests web-form enquiries with strict input sanitization and routes them straight into the CRM
- A modular dynamic-pricing engine driving fast, accurate quote generation
- Advanced dispatch for long-distance, local, cross-border, and multi-leg moves
- Automated Bill of Lading, worksheet, and List of Goods PDF generation for every job
- Fleet management: truck assignment, route planning, fuel tracking, and maintenance
- Staff module for onboarding, payroll, shift scheduling, and HR documents
- Warehouse storage tracking with check-in/out and location mapping
- Two-way Google Calendar synchronization so dispatch and crew schedules stay in step
- A customer portal, role-based access, and an analytics dashboard for KPIs and job costing
Engineering practices
Dependencies are managed with Composer and configuration is kept out of code through environment variables, so secrets never live in the repository. Database changes ship as timestamped, versioned migrations rather than hand-edited tables, which keeps every environment reproducible. The codebase carries an automated-test setup built on PHPUnit and Codeception, and transactional email runs through a templated mailer subsystem so customer-facing messages stay consistent. The integration surface is contained: third-party services like Google Calendar sit behind their own classes, so an external API change touches one file, not the whole system.
Stack
PHP on a custom layered framework with Composer-managed dependencies, MySQL via PDO with prepared statements, a server-side templating layer, PHP-based PDF generation for Bills of Lading and worksheets, PHPMailer/SMTP for transactional email, Google Calendar API integration via OAuth, environment-based configuration, versioned database migrations, and a PHPUnit plus Codeception test setup. JavaScript and jQuery drive the AJAX-heavy operational UI.
Outcome
A $600 project that became a 15-year partnership, and my longest-running client engagement. The platform is used across nearly every province in Canada and replaced manual, fragmented systems with one tool a novice employee can operate. A new version has been in active development over the past year, and the connected-aggregate data model above is the foundation I am using to layer in AI-assisted quoting and dispatch on top of a system that already runs the business.