Meeting Scheduling System.md

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 constraint that shaped everything was a split audience. The people submitting requests are the public, so intake had to be reachable by anyone. The requests themselves describe who is meeting a legislator and when, which is exactly the information that cannot sit on a public surface. One system had to be open at the front and closed at the back.

02 — SOLUTION DESIGN

I designed the intake surface and the record of the request as two separate concerns rather than two tiers of one application. The public form's only job is to accept a submission and hand it off. It holds nothing, queries nothing, and has no view of any request once submitted, so the public surface never becomes a place worth attacking for the data.

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.

Getting that boundary right first is what made the rest buildable. Notifications, per-office approval workflows, reporting, and the Speaker's office enhancements were all added afterward without revisiting the security model, because none of them changed where the data sat. A boundary decided late becomes a rewrite; decided first, it becomes the thing everything else assumes.

03 — ROLE & LEADERSHIP

I led the project and made the boundary decision first, before any feature work started, because every later choice depended on it. I designed the separation between the public intake surface and the request record, and architected a reusable form template with custom handlers so a new office could be brought on by configuration rather than by a new build. I led six developers across frontend and backend, and I ran the demos and pilot sessions with schedulers across the Capitol myself. Adoption was the real risk on this project: a scheduling system nobody trusts is a spreadsheet with extra steps, so the people who would live in it had to be convinced before it was built out.

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.