US Congress Scorecard

Overview

US Congress Scorecard

My role: System redesign to deployed system, run and maintain.

Challenge: Turn a prototype-grade scorecard about US Members of Congress into a secure, deployable system aligned to a WordPress target environment.

Solution: Re-implemented the system with a clean architecture, strong test coverage, and a clear separation between public and administrative capabilities.

Impact: Delivered a production-ready system with segregated admin/public surfaces, hardened secret handling, and a WordPress-native deployment model.

Technologies: Quarkus / Java 21, React / TS

Prototype to Production

The initial codebase was useful for communicating the idea of the scorecard, but it was not a production prototype: features were spread across modules with limited separation of concerns, and the code became difficult to safely change.

Key risks included:

  • no automated tests
  • administrative and public concerns mixed together, preventing a clean security posture for admin functionality
  • secret management issues (e.g., embedded API keys)
  • frontend build tooling choices that were already deprecated, increasing long-term maintenance risk

Initial attempts to disentangle the codebase were time-consuming and high risk, so the delivery decision was to re-implement the system end-to-end while preserving behaviour and improving structure.

Delivery and Technical Approach

The target deployment environment was a WordPress site requiring both administrative and public access. The redesigned system aligns to that environment:

  • the admin experience integrates with WordPress authentication and administration workflows
  • the public scorecard is embedded into WordPress pages via a shortcode and aligns with page theming

Segregated Admin and Public Surfaces

Administrative and public capabilities are separated so that public access remains open, while administrative actions require authenticated access with an explicit security boundary.

The admin SPA is hosted as a subdomain of the WordPress site and is launched from WordPress admin via a link/button. Authentication uses a JWT cookie issued by WordPress: WordPress holds the private key to sign tokens, while the Quarkus backend holds the public key and verifies JWTs.

Backend Architecture and Secret Handling

All sensitive integrations and credentials were moved out of the frontend and into the backend. This reduced exposure of API keys and made access controls auditable and enforceable server-side.

External Integrations

The public scorecard integrates with Google Maps and the US Census API to identify congressional districts and representatives. The administrative workflows integrate with congressional APIs for data ingestion and management (details omitted for client confidentiality).