E-Niyamasabha
Kerala made its Legislative Assembly paper-free in 2020. Five years on, I led the frontend architecture for its next generation: a micro-frontend platform the Assembly's members and secretariat run their proceedings on, built from scratch with a 12-person squad.
Particulars
- Client
- Kerala Legislative Assembly (Govt of Kerala)
- Timeline
- Feb 2025 – Feb 2026
- Role
- Frontend Lead, 12-person squad
- Program
- 30+ engineers, aligned to National e-Vidhan (NeVA)
- Scope
- The question section, a federated micro-frontend
Note · Some implementation details are omitted for confidentiality. This case study covers public parliamentary procedure and general architecture only.
Record summary
140
MLAs served
12
engineers led
10+
question workflows
30+
on the program
The mandate
Kerala was one of the first Indian states to take its legislature paperless, completing the first phase of E-Niyamasabha in 2020. By 2025 it needed a generational rebuild: more of the House's business digitised, a modern frontend stack, and an architecture a large team could extend in parallel.
I joined as the new platform was forming and helped set its direction from the first commit, aligning the build with the national e-Vidhan standard for digital legislatures.
Fig. 01
The question section in the paperless workspace
What I owned
I architected and led the question section: a federated micro-frontend the host shell composes at runtime, exposing its screens and service APIs to the rest of the platform. My squad's remote carried the full question lifecycle, from a member's notice through the secretariat's scrutiny to the minister's answer.
I set the module federation up from scratch, built the role-based access that reshapes every screen for members, secretariat staff, PPOs and ministers, and took the hardest logic myself. Much of the work was translation: turning the Assembly's rules and change requests into software the in-house team could trust.
What the platform digitised
- Minister designation groups, allotment of days, and the calendar of sittings.
- Starred and unstarred questions, with the admissibility ballot.
- Short notice questions, half-an-hour discussions, and questions to private members.
- The answering side: answer bulletins, corrections of answers, and delay statements.
- Rule-referenced scrutiny actions to admit, disallow, or transfer a question, recorded as notes.
Why micro-frontends
Each section of the House's business is its own micro-frontend, composed at runtime by a host shell that shares a single React, Redux, router and i18n instance across every remote. My question section exposed its screens and APIs so the other sections could embed them, and I set the federation up from zero so more than twenty developers could ship in parallel behind stable contracts.
Fig. 02
Architecture: a host shell composing the section remotes
The life of a question
- 01
Notice
A member gives notice of a question, naming the Minister it is addressed to and the date it should be answered.
- 02
Scrutiny and admission
The Secretariat scrutinises the question against the rules; the Speaker admits or disallows it.
- 03
Starred or unstarred
Admitted questions are set as starred, for an oral answer with supplementaries, or unstarred, for a written answer. A ballot and the day's quota decide which starred questions are taken, and the surplus become unstarred.
- 04
Grouped by Minister
Questions are grouped under the Minister they are addressed to and allotted to that Minister's answering day.
- 05
Sent to the department
Admitted questions go to the concerned department, which prepares the answers.
- 06
Question list
The day's question list is compiled and published for Question Hour.
- 07
Answered
In Question Hour the Minister answers starred questions orally and takes supplementaries; unstarred answers are laid on the Table.
Hard parts
- Standing up module federation from scratch for 20+ developers, with shared singletons and stable contracts so squads never collided.
- Turning dense in-house rules into code: the starred and unstarred ballot, where members' questions are clubbed across ballot positions, and the rule-referenced admissibility actions.
- Role-based access across four user types, down to a user's position and role, so the same screen changed per user.
- Bilingual English and Malayalam throughout, including Malayalam-correct PDF output from a dedicated service.
- Keeping many independently owned repositories coherent through a shared design system and disciplined merge-request review.
Outcomes
- Shipped to production across five environments, carrying a question from a member's notice to the minister's answer.
- A federated architecture and shared design system the wider 30+ engineer program builds on.
- A digitised, rules-accurate question process in place of a manual, paper-and-legacy one, backed by a Vitest suite and coverage.
How I approached it
- 01
Understand the institution before the interface
The hard part was getting the House's rules exactly right, so I worked shoulder to shoulder with the in-house team.
- 02
Architecture as a team enabler
The federation boundaries existed so 20+ people could move quickly without stepping on each other.
- 03
One design language across many repos
A shared component library kept every squad consistent.
- 04
Own the risky logic yourself
I took the most complex flows rather than delegating the uncertainty.