LaneDelight
Keep the visit moving. Keep the records straight.
LaneDelight is service-operations software for independent car-wash and express-lube businesses. It connects the vehicle visit, the staff workflow, checkout, membership benefits, and the records a manager needs at the end of the day. It started with a real operation: the first goal is a system that business can depend on; the longer-term opportunity is a platform for other operators, without assuming they all run the same way.
Status: in development, working toward an operational pilot with a design-partner business.
The visit is bigger than the transaction
A car wash isn't always pay first, wash second. An attendant takes the keys and starts service while the customer goes inside, where they might add merchandise, use a membership benefit, pay for an upgrade, or leave a tip. A lube visit may include a wash, with information arriving from a separate system.
Treating all of that as one paid-or-unpaid ticket loses what matters. The car can be washed while the balance is still open. A refund doesn't necessarily mean a service was undone. LaneDelight keeps those facts separate and connects them through the visit: the software reflects the operation, instead of forcing the operation into a simple checkout screen.
Different people need different views
Separate surfaces serve intake and checkout staff, the tunnel operator, management, and the customer. The attendant needs the visit and service fast; the tunnel view needs the vehicle and instructions; the cashier needs the order and what's owed; the manager needs outstanding work and exceptions, not just a sales total.
Uncertainty is a state, not a reason to charge again
If a response is lost mid-payment, the system has to find out what happened to the first attempt before another one is safe. Checkout reserves each payment attempt and reuses its identifiers on retry, and an uncertain result stays visible for recovery instead of being treated as a failure. Payment handling has been exercised in test mode; that proves the software's behavior, not live merchant readiness.
Membership is an entitlement, not another sale
A membership's recurring billing and the benefit used at a visit are related, but they aren't the same event. A covered wash shouldn't create another membership charge at the counter; an extra service or a tip still gets its own treatment. Operator policies are configurable rather than hard-coded to one location's prices.
Close the day without rewriting what happened
Drawers, digital tips, a tip box, unpaid orders, and refunds can each have a different explanation. The close records counts and exceptions against a versioned snapshot; corrections create a new revision with a reason instead of overwriting the old one. A late payment result that affects an earlier close stays visible rather than hidden behind a clean-looking total.
Proven one step at a time
The architecture supports multiple operators and locations from the start. Working software, synthetic end-to-end scenarios, and payment sandbox testing are in place. Hardware qualification, on-site rehearsal, staff training, and a controlled cutover are separate steps still ahead; a successful simulation doesn't prove a camera, printer, or payment device will behave on site.
Built with
React Native and Expo for staff devices; Next.js and React on the web; shared TypeScript contracts across both.