Meeting Scheduling System

01 — CONTEXT

California State Assembly Member offices were fielding a high volume of meeting requests by phone and email. Each request was handled manually, tracked in inboxes and spreadsheets, with no structured way to capture, route, or report on them. As the volume grew, the offices needed a real system, not another workaround.

The challenge was where the data could live. Scheduling information carries sensitivity, so the request data needed to stay on internal infrastructure. The form had to be reachable from the open internet while the data behind it could not be.

02 — SOLUTION DESIGN

The public intake forms are reachable from the open internet, while the request data lives inside internal state infrastructure. Each submission is routed straight through to where that data is kept.

From there, each request is routed into the office's own isolated portal, with permissions scoped so each office's schedulers see only their own data. The data model is designed around opt-in so each office can enable the system and configure its own intake rules independently.

Solving where the data lives was what made everything built on top of it, the notifications, the per-office workflows, the scheduling features, possible within a trusted environment.

03 — ROLE & LEADERSHIP

I led the project. The first problem I had to solve was the one everything else depended on: where the data could live. I designed the split that kept the intake form public while routing all request data to internal infrastructure, and architected the reusable webform template with custom-engineered handlers built by the team. That architectural decision set the foundation for the rest of the system. I led a team of six developers across frontend and backend, brought all the moving parts together, and ran the demos and pilot sessions with schedulers across the Capitol to bring offices on board.

Leading it was as much coordination as engineering. Each Member office had its own workflows, its own expectations, and its own pace. Getting offices to adopt meant showing schedulers, not IT staff, that the system worked for their day-to-day.

04 — TRADEOFFS

Building and running the system on internal infrastructure meant we carried the maintenance ourselves and onboarded offices one at a time rather than handing schedulers a self-service product they could turn on themselves.

We accepted that ongoing cost and the slower rollout because keeping the data secured inside the state boundary was the requirement everything else depended on. The tradeoff was ownership: full control over data residency in exchange for full responsibility over operations.

05 — IMPACT

The system gave each office a single place to receive, organize, and act on meeting requests. Over its lifetime, the platform has processed thousands of requests across participating offices.

The pilot launched with 5 Member offices and, over five years, reached roughly 60 active offices, with the request data secured on internal infrastructure throughout.

The system proved solid enough that I was later assigned to lead the development of the enhanced version for the Speaker of the Assembly's office, the highest-volume office in the California State Assembly, with added capabilities: batch processing, reviewer-based approval workflows, and advanced search.

The platform continues to evolve for Assembly offices today.