"It’s a threat to democracy," says Dev Iyer, Locunity’s CTO, on what happens when local government decisions go uncovered.
Locunity monitors over 200 local government commissions across the United States, city councils, planning boards, school committees, and turns what happens in those meetings into structured intelligence for the people who need it. The pipeline ingests meeting videos, runs transcription, matches findings against what each customer actually cares about, and delivers personalized briefings: 31,000 processing jobs a month, 4.5 terabytes of video and documents processed every week.
For a two-person team operating at that scale, the infrastructure just has to work.
From six-hour meetings to a same-day briefing
Locunity’s pipeline runs continuously. Every time a government body meets, it fetches the video, extracts the audio, runs transcription, and routes the output through a matching engine that personalizes the findings for each customer. Government meetings can run six hours. Video files can hit 10 to 15 gigabytes. The pipeline has to handle that without failing mid-job and starting over.
And the last stage is where the intelligence gets personal. Locunity’s matching engine reconciles what happens in a meeting against what each customer cares about: pending contracts, regulatory exposure, policy fights. "It’s like having a chief of staff that’s analyzing 50 jurisdictions and telling your company what you need to act on today," Dev says. The matching engine turns that reconciliation into a briefing, delivered by email and their native software interface, pushed automatically.
A silent failure, or a job running on stale code after a deployment, shows up not as an error in a dashboard but as wrong intelligence in a Fortune 50 company’s inbox, feeding decisions about government contracts. For Locunity, a background job has to do more than finish: it has to be right, every time.
“
For us, reliability is non-negotiable. I’m willing to invest in that.
”
Reliability is table stakes
"For us, reliability is non-negotiable," Dev says. "I’m willing to invest in that."
Locunity started on Railway. It was an easy place to get moving fast, and for the first few months, it worked. Then the app started going down when customers needed it most. "There was almost an incident every week," Dev says. "Really serious ones that caused us downtime."
There was also an architectural problem. Locunity’s pipeline is evergreen: jobs are always running, always processing, always sending. When Dev deployed new code, it looked successful, but jobs already in the queue kept running on the old code, and customers were receiving briefings built on stale logic. "I would inspect a live container and I could see the commit hash and the files," Dev says. "But it was for some reason sending stale code." He spent significant time trying to debug it on Railway and couldn’t resolve it.
The underlying issue was Railway’s in-process coupling, which made it hard to tell which code was actually running after a deployment. For an async pipeline with discrete processing stages, that ambiguity was a product reliability problem with real consequences for customers, not just a debugging inconvenience.
Clear by design
Dev already ran Cursor with Render’s MCP integration as part of his daily workflow, one of the first MCP integrations he’d used there. When it came time to migrate, he pulled up Render’s Railway-to-Render migration guide and had Cursor generate a full plan. "I thought it would take two or three days," he says. "It just took about three hours." He moved the entire stack over in an afternoon.
"Render’s UX itself caused me to think about how I needed to decouple these services," Dev says. He split the pipeline into five discrete services: a FastAPI web layer, a scheduler, a scraper, a media worker for ffmpeg processing, and a matching engine for policy operations. Web service, cron job, background worker: distinct, separately deployed units with clear jobs, and if one stage fails, only that stage retries.
"I mucked around on Railway for a long time trying to debug this and just couldn’t solve it," Dev says. "When I switched to Render, it just fixed it."
The fix also came with a speed boost. Page loads that had taken four seconds dropped to under one second. "The product just felt so much faster," Dev says. "That was a huge win for us."
Built to scale, built to stay lean
The 200 commissions Locunity covers today are the starting point. The target is 10,000. Scaling from here is primarily a question of compute: more CPU and RAM allocated to more jobs, more video processing, more document ingestion. Dev has Render’s autoscaling configured as a backstop for sudden spikes. "As long as Render can abstract the infrastructure management on the back end, it takes a lot of work off my plate," he says. "Render is doing what I don’t want to work on. I need to focus on customers and scaling."
"Five years ago, what Locunity is doing would have required a team of seven engineers," Dev says. Now AI handles the coding, Render handles the infrastructure, and Dev handles the product and customers. And the same matching engine now tracks the UN General Assembly.
The 10,000 jurisdiction goal isn’t a distant ambition. Locunity plans to cover the entire state of California by the end of the year, running on a pipeline built to scale without infrastructure becoming Dev’s job. Every new commission is another city council, planning board, or school committee whose decisions don’t go uncovered.