Live crowd-density alerts for temples, melas and stadium events
TL;DR Throngline reads the CCTV feeds a venue already has, plus a few temporary cameras, and estimates how many people stand in each square metre of a choke point. When density climbs toward a danger line, the control room gets an alert while there's still time to act. Temple trusts, event organisers and stadium operators pay per event or per season.
India counted 3,074 stampede deaths between 2000 and 2022 in NCRB data, across nearly 4,000 incidents over three decades[1]. The recent list is grim. At least 121 died at a religious gathering in Hathras in 2024, and there were deaths in 2025 at the Maha Kumbh, a Tirupati token counter and a Karur rally[1]. On 4 June 2025, 11 people died outside Bengaluru's cricket stadium when, by the state's own court testimony, about 2.5 lakh fans turned up to an event held without a standard operating procedure[2].
Most of these venues had cameras. What they didn't have was a number on a screen telling someone that the crowd at one gate had become unsafe, while there was still time to stop more people coming in.
The seed pitched pedestrian tracking to make public spaces more efficient. Nobody in India pays much for that, honestly. Organisers and venue owners do face inquiries, arrests and suspensions after a crush, so I've pointed the same technology at safety.
Throngline maps a venue's choke points (gates, ramps, queue lines, bridges) and calibrates each camera to the floor area it sees. Its models count heads and estimate density and flow direction every few seconds. Each zone gets thresholds agreed in advance with the organiser and local police, and each threshold is tied to an action - close a gate, hold a queue, open a relief route. Alerts go to the control room screen and to marshals' phones.
For one-off events, a small team sets up temporary cameras, sits in the control room and hands over a post-event report. Temples and stadiums with recurring crowds get it as a subscription on their own cameras.
Whoever carries the liability pays. That means temple trusts and devasthanam boards, organisers of concerts and sports events, stadium associations and mela authorities. Police are the main user in the control room but they're rarely the payer. There's no public price list for crowd analytics in India, so the price per event day and per season subscription are things to test in the sprint.
The 2025 run of crushes has pushed organiser accountability into public debate, with proposals for a Crowd Safety Act that would define organiser liability[1]. NDMA guidance already asks venues to run CCTV control rooms and set density limits with evacuation triggers[3]. Camera density analytics are named in that debate as a practical tool[1].
There is no public figure for what Indian venues spend on crowd analytics. The firmer signals are the scale of the risk, 3,074 recorded deaths over 23 years[1], and the size of single gatherings, with 2.5 lakh people outside one stadium on one afternoon[2]. Treat the market as the set of recurring large venues and festivals, counted one by one.
Swiss and other foreign firms with Indian offices sell 3D people-counting sensors and flow software for airports, transport and live events[4]. Large cities run integrated command centres with camera analytics bought through smart-city tenders. Event security agencies supply marshals but not measurement. The gap is a service that turns density into agreed actions and stays in the room during the event.
| Difficulty | Moderate (48/100) |
| Starting capital | ₹1.2–2.2 Cr |
| Time to launch | 9–12 months |
Counting heads in a dense Indian crowd from an old, badly placed camera is hard, and accuracy drops exactly when density rises. The other hard part is human. Thresholds mean nothing unless police and organisers agree beforehand who closes which gate, and then actually do it.
No operating licence as such, but you work inside the permissions police and venues already hold.
Building this outside India? The categories above usually have a local equivalent, so check with your own regulator.
Don't let AI make the call to close a gate or stop a procession. It flags, and a trained officer decides, because a false alarm in a packed crowd can cause the very panic you're trying to prevent.
Want to work out the AI layer for Throngline? Talk to Yash →
I think it's worth pursuing for a founder who has run event operations or worked in a police or disaster-management control room, paired with a computer-vision engineer. A pure software founder will struggle with the field work. Prove first that your density estimate stays within 20% of a manual count at two real packed events.
Plan for roughly ₹1.2–2.2 Cr, most of it on computer-vision engineering, temporary cameras and a field team for events. Using a venue's existing CCTV keeps the hardware spend down.
No sector licence, but the organiser needs police permission for each event and you should follow NDMA crowd guidance. If you ship wireless kit, WPC type approval applies, and camera data falls under the DPDP Act.
Yes. Stadiums, festivals and transit hubs everywhere face the same risk. Check local privacy law on CCTV analytics and how event safety duties are split with police before you sell.
The free Throngline validation kit has the line-by-line capital breakdown, the effort scoring, the data-protection and venue-permission checklist, a 14-day validation sprint with pass/fail targets, a 90-day launch plan, 10 interview questions for venue owners and organisers, and 5 assumptions to test. Download the kit →
Thinking about building Throngline or something close to it? The make-or-break bit is getting police and organisers to agree on thresholds and actions before the first event, and that's a conversation I can help you prepare for. If you need a hand, you know where to find me. Talk to Yash →
For illustration only. Names are fictional and ideas hypothetical; sourced facts are real but may be out of date. Nothing here is legal, financial or professional advice, and Yash Khatri is not personally liable for any use of it. Read the full disclaimer.