Paper valet tickets fail in predictable ways. Stubs get lost, runners can't tell which request came first, and managers have no live view of the cars on site.
At Divtechnosoft, a custom software engineering agency that builds web apps, mobile apps and SaaS products for startups and scale-ups, we replaced that paper system for Summon, a digital valet platform. It now runs at 450+ locations, including hotels, restaurants, malls, hospitals, stadiums and large events, on infrastructure that costs under $40/month. The full project is covered in our digital valet management platform case study.
Here's how we approached it, and what other teams can take from it.
Three apps, one codebase
A valet product is really three surfaces:
Guest experience: guests get an SMS with a digital ticket link. They can request their car, pay by Apple Pay or card, and add extras like a car wash or EV charging.
Operator app: attendants log vehicles, record their condition, assign parking spaces and receive retrieval requests.
Operator portal: managers use a web dashboard to track driveways, shifts, tickets and revenue across locations.
We built all three with Ionic and Angular, sharing models and services across them. Capacitor ships the operator app to iOS and Android. Firebase handles data and backend functions, and Stripe handles payments.
The ticket is the core
Every car gets one digital ticket, and each ticket moves through a simple set of statuses: parked, requested, en route, delivered. Every screen in the system reads from that ticket, so guests, runners and managers all see the same state.
Each ticket also carries its location. That one decision makes it easy to show staff only their own venue and to report on each location separately.
A live, priority-sorted queue
The runner's screen is a live list of cars waiting to be retrieved. It updates the moment a guest taps "request my car", without anyone refreshing.
The list is sorted by priority, worked out from three things:
- Scheduled pickup time: a guest who booked a 7:30 pickup moves up as 7:30 approaches.
- VIP status: set by the venue.
- Wait time: among equal requests, whoever has waited longest goes first.
Because the priority is calculated once and saved on the ticket, every device shows the same order.
Staff only see their locations
Operators often run several venues. Each staff account is assigned to specific locations, and Firebase security rules enforce it, so an attendant at one hotel can't see tickets from another site.
Payments handled on the server
The guest's phone never calculates the price. The backend works out the total from the parking fee and any add-ons, then creates a Stripe payment. Apple Pay appears automatically on supported devices, and payment is only marked complete once Stripe confirms it.
How we kept infra under $40/month
- Track only active tickets live. Delivered tickets drop out of real-time updates.
- One live connection per screen, not one per car.
- No polling. Real-time updates only send what has changed.
- Archive old tickets automatically, so the live database stays small.
- Backend functions scale to zero when idle.
- Compress vehicle photos on the device before upload.
Key takeaways
- Build around one clear object, here the ticket, with a few well-defined statuses.
- Make the queue real-time and sort it the same way on every device.
- Lock data to locations from day one if the product will serve many sites.
- Keep pricing and payment confirmation on the server.
- Design for low running costs early. It's much harder to fix later.
For the full story, including features, outcomes and the client's feedback, see the Summon case study by Divtechnosoft.
Have you built a real-time queue for a service business? We'd like to hear how you handled priority. Share it in the comments.
Top comments (0)