Traditional lots depend on heavy manpower and give drivers little live availability data. RFID and dense sensor networks raise cost in lockstep with bay count. The product bet was different: detect occupancy from camera feeds, expose statistics operators can act on, recognise plates with OCR, and let drivers book and pay in a mobile app with card and PayPal-style gateways.
What had to be true in production
Occupancy detection must be real-time enough for drivers and operators. Statistics must be configurable, not a fixed dashboard. Plate recognition must be accurate enough for enforcement and customer service. Booking and payment flows must survive partial failures. None of that is a one-sprint demo: it is ongoing evaluation, monitoring, and release discipline.
| Capability | Why it needs continuity |
|---|---|
| Occupancy detection | False empties destroy trust immediately |
| Operator statistics | Requirements change by site and contract |
| License plate OCR | Accuracy drifts with lighting and camera placement |
| Mobile booking and payments | Payments and availability must stay consistent |
Dedicated team, not a rotating AI bench
AI features fail quietly when the people who tuned the pipeline leave after a project warranty. A dedicated India engineering team keeps model operations, backend APIs, and the mobile client under one backlog and one leadership rhythm. You approve hires and keep product priorities; MedRec carries employment, workplace, and retention so the squad can stay on the problem.
This is also why industry context matters. Parking operators in the UK, UAE, US, and wider Europe care about labour cost and bay utilisation in different ways, but they share the same engineering need: durable ownership of a live system, not a slide deck of accuracy claims.
From pilot to production
Smart parking pilots often look impressive in a single car park under good lighting. Production is different: cameras at awkward angles, rain and glare, dirty or damaged plates, and peak-hour traffic that tests every part of the system at once. The work that matters is making recognition reliable across those conditions and handling uncertainty gracefully when it is not.
That means designing for the exceptions, not just the happy path. What happens when a plate cannot be read? How does the operator review and correct it? How are bookings and payments reconciled if a camera goes offline? These questions decide whether operators trust the system enough to rely on it.
Why one team needs to own the whole flow
Occupancy detection, plate recognition, booking, and payments are often built by different groups. Problems then appear at the boundaries: a recognised vehicle that does not match a booking, a payment that succeeds while the barrier stays closed, an occupancy count that drifts from reality over a day.
A single dedicated team that owns the full flow can trace an issue from camera frame to payment record without waiting on hand-offs. It can also prioritise sensibly, by fixing the edge case that causes most operator complaints rather than polishing the part of the system it happens to own.
What to measure
Useful measures go beyond model accuracy in a test set. Track recognition success in live conditions, the share of events needing manual review, time to resolve exceptions, and payment reconciliation errors. Review them with operators regularly; their feedback is often the fastest route to the improvements that matter.
Working through this in your own GCC plan?
We will give a direct answer on a short call.
