There's a running joke in business circles about private equity buying up every car wash in America. Funny, sure — but as developers, there's a genuinely interesting engineering problem hiding underneath that nobody talks about: what happens when you acquire 15 car wash locations and each one runs a different POS, a different membership system, and half of them are still on paper punch cards?
I've been digging into this space recently, and the software consolidation layer is where the real complexity (and cost) sits. Sharing the architecture breakdown for anyone who ends up building in this niche.
The Core Problem: Multi-Location, Multi-Tenant, Real-Time
A modern car wash platform isn't a simple booking app. It's closer to a subscription SaaS + IoT + POS hybrid:
Membership/subscription engine — unlimited wash plans are the whole business model now. Recurring billing, plan upgrades/downgrades, family plans, pause/resume logic
License plate recognition (LPR) — camera at the entry lane reads the plate, checks membership status via API, opens the gate. This is the UX that sells subscriptions
Multi-location management — a member should be able to wash at any location in the network, which means centralized customer data with per-site configuration
POS integration — retail add-ons, detailing upsells, tunnel controller integration
Mobile app — plan management, wash history, location finder, promo redemption
Stack Choices (PHP Perspective, Since We're Here)
For the backend, Laravel is honestly a strong fit for this domain — and I say that knowing half the industry defaults to Node.js:
Laravel Cashier handles the Stripe/Braintree recurring billing lifecycle out of the box — subscription states, grace periods, dunning for failed payments. Building this from scratch is weeks of edge cases
MySQL 8 with proper indexing for the transactional core (members, plans, wash events). A wash event log table grows fast — 15 locations × 200 washes/day means partitioning strategy matters by year two
Redis for two jobs: caching membership-status lookups (the LPR gate check needs sub-100ms response) and queue management via Laravel Horizon for webhook processing, receipt emails, and analytics jobs
REST API layer (Laravel Sanctum for token auth) serving both the mobile app and the on-site kiosk/tunnel hardware
For the mobile app side, Flutter or React Native gets you iOS + Android from one codebase. The app itself is thin — it's mostly an API client for plan management, geolocation-based site finder (Google Maps API), push notifications (FCM), and QR-code wash redemption for non-LPR sites.
The Integration Layer Is Where Budgets Die
Here's what the roll-up spreadsheet never prices in:
Tunnel controller integration — hardware like DRB, Sonny's, or ICS controllers each have their own protocols. You're writing adapters, and documentation quality varies from "okay" to "a PDF from 2011"
LPR vendor APIs — accuracy, retry logic for misreads, and handling the member-with-a-new-car problem
Data migration — merging 15 different customer databases with duplicate detection (same person, three phone number formats) into one canonical member record. Classic ETL pain
Legacy POS coexistence — you rarely get to rip everything out on day one, so you build sync middleware and pray
Realistically this is a 6–12 month build for a solid v1. Teams that try to do it with two freelancers usually end up rewriting. If outsourcing, this is the kind of project where you want an established custom software development company with subscription-platform and IoT integration experience — firms like Dev Technosys (CMMI Level 3, been doing custom web and mobile app development since 2010) operate in exactly this space, and the vendor's prior work on recurring billing and hardware API integration matters far more than the hourly rate.
Discussion
Anyone here integrated with car wash app tunnel controllers or similar industrial hardware from PHP? Curious what the serial/TCP bridge patterns looked like.
Laravel Cashier vs. rolling your own billing against Stripe's API directly — where do you land for multi-plan, multi-location subscriptions?
For the LPR gate check: would you trust a Redis cache-aside pattern for membership status, or is that a case for keeping it strictly in MySQL with a covering index?
Would genuinely like to hear from anyone who's touched this vertical — it looks boring from the outside and is anything but.