01 / PROBLEM
A focused view of a broad data source.
Congress.gov contains extensive legislative information, but following a specific subject requires collecting and connecting information across bills and actions. Our thesis project focused on legislation related to mathematics and STEM education, tracking and presenting more than 500 U.S. congressional bills.
Allison Berkowitz and I co-built a database and website for a project with Professor Courtney Gibbons at Hamilton College. The intended audience included researchers and congressional staff who needed an easier way to follow relevant legislation.
02 / CONTRIBUTION
My contribution: connecting the pieces.
This was a shared full-stack project. I worked on connecting the application to its data source, deploying it on Vercel, and configuring scheduled ingestion. My commit history records the move away from a local API connection, deployment troubleshooting, batch-size adjustments, and the final cron configuration.
Database integration
Helped move the website from a local development endpoint to a deployed API connection, with work on the connection layer and CORS configuration.
Scheduled processing
Adjusted the ingestion batch size to 150 records and configured daily jobs for bill ingestion and subscriber synchronization.
Application integration
Contributed to the React application, including the alerts layout, as the frontend and data pipeline came together.
03 / DECISIONS
The architecture follows the workflow.
The backend queries Congress.gov summaries, checks titles and summaries against a defined keyword set, and enriches matching records with sponsors, cosponsors, committees, and related bills. MongoDB stores the records and the ingestion progress.
The React frontend reads through a serverless API. Users can search by title or bill number, filter by representative or state, and open a detail view. Mailchimp handles the email-alert integration.
Batch work around execution limits
Each invocation processes one batch and persists an offset. That creates a continuation point for a later run instead of requiring one function to finish the whole dataset.
Make the selection rule inspectable
Keyword matching gives the project a concrete, explainable definition of relevance. Its tradeoff is coverage: bills can be missed when they use different language.
Keep the reading experience focused
The interface exposes search and filters and initially shows 20 actions. Filtering happens in the browser; the API still returns the full dataset.
04 / CHALLENGES
Deployment was part of the engineering.
Connecting locally was only one step. The deployed app also needed the right API paths, environment configuration, cross-origin handling, and scheduled execution. The commit history shows repeated iteration on these boundaries.
The repository documents daily cron jobs. Keeping historical records and new bill actions in sync is an important data-quality consideration for the pipeline.
05 / TAKEAWAYS
What this project makes clear.
A useful application depends on the whole path from external data to the interface. Integration details, update behavior, and clear information structure matter alongside the individual components.
Reliability is the next layer
A next iteration should add explicit deduplication, retry behavior, and stronger progress tracking so interrupted or repeated runs do not create duplicate records.
Scale the query, not just the display
Server-side search and pagination would reduce the amount of data sent to the browser as the collection grows.
Make maintenance easier
Automated checks and a cleaner repository that excludes installed dependencies would improve reproducibility and handoff.