Built as infrastructure.
DeepQ is a real-time queue engine with a versioned API, a live update layer, and a multi-tenant deployment model. Here is what it's made of.
Applications
Customer, floor console and network dashboard — three purpose-built surfaces on one platform
Delivery
Static delivery over CDN, with authentication at the edge
Core
Queue engine, booking engine, and a real-time hub — separable concerns, not one tangle
Data
Managed SQL with a cache layer in front for the hot path
Operations
Automated pipeline, monitoring, analytics
What the queue engine actually does.
Unified intake
Appointments, walk-ins and remote queue-joins enter one ordered queue.
Automatic ordering
The queue orders itself. Staff can search and filter without disturbing the order.
Live estimates
Wait times derived from real service durations, recalculated as the floor changes.
Mid-service change
Services added or removed in-chair; duration and price update live, and the queue behind updates with them.
Exception handling
Reassign, return to queue, no-show, cancel — as first-class actions, not workarounds.
Group sessions
Multiple people, multiple services, one booking, one token, one queue position.
On the roadmap: telling customers when to leave
Most queue systems tell a customer how long they’ll wait. The more useful question is when they should leave home.
DeepQ is being built to answer it — estimated service start, minus the travel time the customer gives us, minus a buffer. The customer supplies that in one tap. We don’t track their location, and we don’t ask for access to it.
In development, with our diagnostic centre deployment.
Deployment model
Multi-tenant
One platform, independent brands. Each brand's customers see only that brand's locations.
Multi-location
Location-scoped operator accounts; network-scoped oversight accounts.
Rollout by location
Start with one branch. No big-bang migration.
It sits alongside what you already run.
DeepQ exposes a versioned REST API. It is designed to receive events from the systems you already operate — bookings from your existing scheduler, arrivals from your front desk — rather than requiring you to move off them.
Deeper integration with hospital and clinic information systems is on the roadmap and is scoped per deployment.
Technical specification
- Front end
- React · TypeScript
- API
- Node.js · Express · REST, versioned
- Authentication
- JWT for operators; OTP for end customers
- Database
- Managed SQL, with a cache layer
- Real-time
- SignalR, with Server-Sent Events fallback
- Delivery
- Static web hosting over CDN
- Deployment
- Automated CI/CD pipeline
- Cloud
- Microsoft Azure · Indian region
Security and data
Role-scoped access
Operators see one location. Oversight accounts see their own network and no other.
Minimal collection
Name and mobile number for a customer booking. Nothing more is required.
Data residency
Deployable in an Indian Azure region.
DPDP-aligned
Built to the Digital Personal Data Protection Act, 2023.
Tell us how your floor runs today.
We'll tell you honestly whether DeepQ helps — and what it would take to run it in one of your locations.