Inside RushHour — how we route a job in under five seconds.

Most home-services platforms are batch-matchers. You submit a job. They notify N pros. The pros pick. Time-to-acceptance is measured in tens of minutes, sometimes hours.

RushHour is a real-time router. From the moment a customer commits a job to the moment a verified pro accepts is a sub-five-second loop on Srinagar median. It's a different design from the ground up.

The three moves

First: at job-submit time, we compute an eligibility set in milliseconds — pros who are online, in radius, in tier, in skill, and not over their daily acceptance cap. This filtering happens against an in-memory snapshot of supply state, refreshed by a stream of presence and acceptance events.

Second: we score every eligible pro using a composite of distance, Trust Score, recency of work in the area, and predicted acceptance probability. The scoring runs in a single pass. We don't iterate.

Third: we offer the job to the top pro for a small acceptance window (default seven seconds). If declined or expired, we cascade to the next, and the next, until accepted or exhausted.

Why this matters more than the mean

Batch matchers optimise for fairness across pros. Real-time routers optimise for the customer's anxiety curve. The first thirty seconds after a service request are when trust is built or broken.

We chose the customer.

Patent and what's next

The architecture is filed: IN 202511047332. We are extending it to multi-leg dispatch (group jobs, multi-pro coordination) and to predictive supply pre-positioning during demand surges. Sprint 6 territory.