- Platform
- iOS, Android, Web app
- Duration
- 16 weeks
- Industry
- Civic Tech
- Read time
- 9 min read
In short
RaftLabs built Voter IQ, an Indian civic tech platform for regional political engagement in Andhra Pradesh. The mobile app (iOS and Android) and web admin panel support a four-tier permission model (mobile app admin, badge holders, non-badge-holder citizens, and super/sub admins), real-time audio discussions via Agora, live polls and comments for citizens, and a constituency-level issue escalation chain routing local concerns up through party hierarchy to MLA and MP levels. The platform was load-tested with Artillery.io and k6.io: the infrastructure sustained 7,000–8,000 concurrent live-discussion users on a single m5a.large EC2 instance, with a documented scaling path to 60,000–70,000 via horizontal scale-out. Delivered in 16 weeks to meet an election-cycle deadline.
Political discussion inside Indian constituencies ran asynchronously. A senior leader would hold a discussion, and the outcome would trickle down through the ranks with no guarantee everyone stayed aligned. Citizens had no single platform to follow what their party leaders were actually saying. Existing platforms had no mechanism to confine discussion to a specific political network. There was no private, party-specific space for it.
There was also a hard deadline behind the build. Elections were approaching during the first project phase. If the app had not shipped in time, it would not have been usable for that election cycle at all.
Voter IQ's founders needed a structured live-audio platform: party leaders at different hierarchy levels holding discussions, local issues escalating upward through the right chain of command, citizens listening, commenting, and voting in polls, all within private, party-specific networks. We delivered the mobile app (iOS and Android) and web admin panel in 16 weeks against that election deadline. When the client later asked whether the system could handle 200,000 concurrent users, we ran real load tests, found the actual ceiling, and gave a costed, honest path forward.
before & after
What changed
- Political discussions inside constituencies were asynchronous, with no way for leaders at different levels to convene and discuss together directly
- Gathering the right leaders for an important discussion was manual and tedious: individual invitations followed by repeated follow-ups every time
- Citizens had no single platform to follow what their party leaders were discussing; coverage was scattered across YouTube, television, and other channels
- Existing platforms like X had no mechanism to confine discussion to a specific political network, with no private party-specific space
- There was no defined chain for surfacing local constituency issues to the right decision-makers at higher levels
- Real-time audio discussions with defined roles (host, co-host, speaker, and listener) within a private, party-specific network
- A four-tier permission model (mobile app admin, badge holders, non-badge-holder citizens, and super/sub admins) enforced clear participation rules at every level
- Citizens could follow live discussions, comment, and vote in polls within their party network without being promoted to the leadership tier
- A defined issue-escalation chain routed local constituency concerns upward through party hierarchy to the right decision-makers at MLA and MP levels
- Load testing confirmed the infrastructure could sustain 7,000–8,000 concurrent live-discussion users, with a documented, costed path to 60,000–70,000 if traffic ever demanded it
What we had to solve
- 01
Answering a direct scale question with load tests, not guesses
The client asked directly: could the platform support 200,000 concurrent users in a live discussion, each polling and chatting? Rather than answer with confidence alone, we ran structured load tests using Artillery.io for HTTP traffic and k6.io for WebSocket connections. At 1,000 concurrent users generating 2,000 requests over 100 seconds, the platform hit 100% success rate with a p95 response time of 347ms. At 5,000 users, 7,824 of 10,000 requests succeeded with p95 around 3.1 seconds. WebSocket testing found the system could sustain roughly 7,854 simultaneous connections before connection latency started climbing (a ceiling constrained by the local test setup, not confirmed as the system's true limit). The finding was honest: 7,000–8,000 simultaneous live-discussion users on the existing single-EC2 setup, with a clear, costed horizontal scaling path to 60,000–70,000 if usage ever demanded it.
- 02
Making network member counts agree across two separate apps
The platform needed several distinct counts (total network members, badge-holder counts, and non-badge-holder counts) displayed consistently on both the mobile app and the admin panel. Using one generic member count would have created visible inconsistencies. Defining explicit counting rules per member type kept both apps in agreement. A separate issue compounded this: deleted users were still being counted toward network totals, making a network showing 500 members show only 200 real users on its detail screen. Rather than fix this at the mobile app level, a riskier change, we applied a backend-level fix to exclude deleted users from all counts entirely.
- 03
Separating network membership from following as distinct data concepts
Badge holders auto-follow other badge holders and the mobile app admin within their network when they join. But network membership itself needed to be treated as a completely separate mechanism from following; conflating the two would have broken the counting logic above and created permission edge cases. Enforcing this distinction explicitly in the data model meant the permission system behaved correctly across all role combinations, not just the common cases.
- 04
Diagnosing a production Agora audio token authorization failure
In production, the client hit an Agora audio SDK error: CAN_NOT_GET_GATEWAY_SERVER (invalid token, authorized failed). The user ID was being passed as a UUID string, which the SDK flagged as a likely cause. Switching to a numeric UID resolved the authorization failure. The fix was small, but the diagnosis mattered: this surfaced in production rather than testing, and the root cause was a subtle API contract detail (not a configuration error) that required understanding how the SDK expected the UID parameter to be typed.
outcomes
What we achieved
There was a hard deadline behind the build: elections were approaching, and if the platform did not ship in time, it would not be usable for that cycle at all.
The client asked directly whether the platform could support 200,000 concurrent users. Rather than answer with an estimate, the team ran structured load tests with Artillery.io and k6.io to find the real ceiling.
Political discussion platforms need structured roles (host, co-host, speaker, listener, party leader, citizen, and admin) that enforce the real hierarchy of a political network, not a generic user model.
Building a real-time audio platform against a hard deadline?
the build
What we built
Voter IQ is built around the insight that political discussion inside a party network needs structure: defined roles, a clear escalation path for local issues, and private spaces that exclude the noise of public platforms.
Four-tier permission model that reflects real political hierarchy
The platform supports four distinct user tiers: mobile app admins who manage their party network, badge holders (party leaders) who auto-follow other badge holders and the network admin when they join, non-badge-holder citizens who participate as listeners, commenters, and voters without entering the leadership tier, and super admins and sub-admins who manage the platform from a separate web panel. Each role maps to a distinct set of discussion permissions enforced at the data layer. The admin panel scope expanded significantly once it became clear the client needed many actions performable by admins on a user's behalf, not just by users themselves.
Live audio discussions via Agora, with a resolved production auth issue
Real-time audio discussions run through Agora's SDK, supporting live hosts, co-hosts, speakers, and listeners in session. When a production token authorization failure surfaced (CAN_NOT_GET_GATEWAY_SERVER), the fix was switching from a UUID string to a numeric UID for the Agora user parameter: a subtle API contract detail that changed the authorization behavior entirely. The platform also supports live polls and comments within sessions, giving citizens a way to engage without taking the floor, and surfacing collective signal in real time as discussions unfold.
Issue escalation chain from constituency leaders to MLA and MP levels
Constituency issues surfaced by local leaders needed a defined path upward through the party hierarchy. The escalation model connects discussion participants at each tier so local concerns can be routed to the right decision-makers at MLA and MP levels rather than staying isolated at the constituency. The chain maps directly to the platform's permission tiers: constituency leaders escalate to the next level, not to a generic inbox.
Load testing that gave a real answer, not a confident estimate
When the client asked whether the platform could handle 200,000 concurrent users, we ran structured tests rather than estimating. Artillery.io handled HTTP load scenarios; k6.io tested WebSocket connections. The infrastructure at the time (a single m5a.large EC2 instance at roughly $38/month) comfortably sustained 7,000–8,000 simultaneous live-discussion users within acceptable response times. A 3–4x horizontal scale-out would reach approximately 60,000–70,000. We recommended against provisioning always-on scaled infrastructure until the platform had proven, sustained traffic to justify the added recurring cost. We documented both the honest ceiling and the costed path to scale it.
Engagement
How we worked together
- 01Weeks 1–2
Discovery and scoping
We map the problem before writing code. Two weeks of technical audit, stakeholder interviews, and prototype — so both teams align on scope and risk before sprint one.
- 02Ongoing
Two-week Agile sprints
Each sprint ends with working software, not a status update. You review a real build, request changes, and approve before we move forward. No surprises at handover.
- 03Ongoing
Daily async updates
Slack for daily progress, Asana for task visibility, weekly video calls for decisions. You have full visibility without needing to attend every meeting.
- 04Final
Handover and warranty
Full code handover with deployment runbooks and documentation. Thirty-day warranty period for production issues at no extra cost.
stack
Why we chose this stack
- 01
Agora
Real-time audio for live political discussions with hundreds of simultaneous participants requires infrastructure built specifically for that load. Agora's SDK handled low-latency voice, adaptive bitrate for varying connection quality, and the host/speaker/listener role model the platform needed. Building on raw WebRTC would have required managing the connection mesh ourselves; Agora abstracted that complexity while still giving us control over session management and token-based room access.
- 02
Firebase
Analytics and push notifications needed to be tracked independently from the primary application backend. Firebase Analytics gave the client visibility into mobile event data without coupling it to backend instrumentation, and push notifications could be delivered reliably without building a separate notification pipeline.
- 03
AWS
Lambda handled serverless event processing for the platform's background operations. The main backend ran on a single m5a.large EC2 instance, deliberately lean at roughly $38/month. The load testing exercise confirmed this was the right call: the infrastructure handled 7,000–8,000 concurrent users well within acceptable limits, and scaling it horizontally to 60,000–70,000 is a documented option rather than a speculative one. Over-provisioning for a 200,000-user hypothesis that hadn't materialized would have added recurring cost with no justified demand behind it.
- 04
React Native
A single codebase for iOS and Android reduced development effort for the mobile app while still allowing platform-specific behavior where Agora's SDK and push notification handling required it. The shared codebase also made it easier to keep the two app versions consistent as the permission model and discussion features evolved over the engagement.
Common questions about Voter IQ
Badge holders (party leaders) auto-follow each other and the network's mobile app admin when they join the network. Non-badge-holder citizens can join discussions as listeners, commenters, and voters without being part of the leadership tier; the distinction between membership in a network and following within it is enforced at the data layer, not just the display layer. Super admins and sub-admins on the web admin panel can perform key actions on users' behalf, a requirement that expanded the admin panel's scope significantly once the client's real usage pattern became clear: rather than expecting end users to handle all actions themselves, the client needed admins to be able to manage users directly from the panel.
We ran HTTP load tests with Artillery.io and WebSocket connection tests with k6.io, simulating multiple scenarios. At 1,000 concurrent users generating 2,000 requests over 100 seconds, the platform achieved a 100% success rate with a p95 response time of 347ms. At 5,000 users, 7,824 of 10,000 requests succeeded with p95 around 3.1 seconds. WebSocket testing found the system could sustain roughly 7,854 simultaneous connections before connection latency started climbing (a ceiling constrained by the local testing setup, not confirmed as the system's true limit). The honest conclusion: the infrastructure at the time handled 7,000–8,000 simultaneous live-discussion users comfortably. Reaching 200,000 concurrent users would require an architectural shift, not a single configuration change, and a 3–4x horizontal scale-out of the existing setup would land around 60,000–70,000, not 200,000. We documented this clearly rather than over-promising on a hypothetical.
Local party leaders can surface constituency-level issues within the platform. The escalation model defines who receives that issue at the next tier of the hierarchy: constituency leaders escalate to their MLA, MLAs escalate toward MP level, and so on. Each tier in the escalation chain maps directly to the platform's permission tiers, so issues travel through the actual political decision-making structure rather than arriving in a generic inbox. The chain is not a notification system; it is a structured discussion pathway that connects the right level of the hierarchy to the right concern.
Existing platforms have no mechanism for private, party-specific discussion networks with defined role hierarchies. A Zoom call cannot enforce a four-tier permission model, limit participation to verified party members, or maintain an auditable record of discussion tied to constituency hierarchy. WhatsApp groups have no live audio model or structured escalation path. X is public by default with no party-private space. Voter IQ is purpose-built: discussions are private and party-specific, roles are enforced at the data layer, citizens can participate without being promoted to leadership tier, and the issue escalation path is defined rather than improvised. For political organizations that need both confidentiality and a structured chain of accountability, that structure cannot be bolted onto a general-purpose platform.
We delivered the full Voter IQ mobile app (iOS and Android via React Native), web admin panel with super admin and sub-admin roles in separate live and staging environments, four-tier hierarchical permission model, real-time audio via Agora including a resolved production authentication issue, constituency issue escalation chain, and load-tested infrastructure in 16 weeks. The most complex pieces were the permission model (where network membership and following had to be kept as distinct concepts with distinct counting rules that agreed across two separate apps) and the production Agora auth failure that required diagnosing a subtle SDK parameter contract. A platform with fewer permission tiers, no issue escalation chain, or without the load-testing exercise would be faster to build. Contact us to scope based on your user hierarchy, audio requirements, and expected session load.
Related work
More work like this
AI phone agents automate global feedback loops through voice interviews
We transformed a text-based AI interview platform into a voice-first system that conducts automated phone interviews globally, eliminating user friction and delivering richer insights through natural conversations.
Read case study
Multi-location gas station operator processes 20k+ daily transactions after replacing spreadsheets with AI OCR software
This purpose-built gas station inventory management software uses AI-based OCR to automate invoice processing and unify inventory, sales, and vendor tracking. Designed for scale, it gives owners real-time control across 40+ locations without disrupting existing POS systems.
Read case study
UrShipper's fifth attempt at a multi-carrier shipping platform processed 2,000 shipments across 70+ countries in year one
Four previous vendors had failed to deliver. RaftLabs was UrShipper's fifth attempt. We rebuilt the platform in 14 weeks: 200+ customers migrated without disruption, 92 new businesses signed up in the first two months, 2,000+ shipments processed across 70+ countries in year one.
Read case study
