CountBubble — Nonprofit Case Management & Custom Reporting Engine

Overview & Legacy Constraints

CountBubble is an established SaaS platform that helps human-services nonprofits coordinate daily case management, track participant outcomes, and manage operational records. Joining this project meant stepping directly into an active, multi-year production system with real user data and strict architectural conventions.

The stack operated without modern framework conveniences:

The frontend was built on React 16 using a custom internal UI component library and manual state handling. The backend used untyped JavaScript running on AWS SAM (Serverless Application Model), coordinated locally through Express and Docker. Instead of an ORM, the data layer relied on a mediator design pattern where database interactions were written as raw SQL queries across large repository files, with migrations managed manually through numbered SQL scripts.

Because the system was actively serving clients, I did not have open access to inspect production database volumes directly. Every change required careful local testing to guarantee backward compatibility without breaking existing records or slowing down serverless execution.

Getting Started: Participant Assignment

My initial work on the platform focused on adding a participant assignment system. Nonprofits needed the ability to link participants directly to one another for coordinated care and oversight.

This feature spanned the full stack, requiring new endpoints in the serverless backend, updates to raw SQL queries, and integration with the custom React 16 frontend interface. Working through this first deliverable gave me a grounded understanding of the mediator architecture, how data flowed through the application, and how to safely update the database schema without disrupting existing production tables.

Transforming the Reporting Section

After delivering the initial feature set, I took ownership of the reporting engine. Originally, the reporting area was a basic, single-page view with no saved configurations or historical state. I rebuilt this section into a comprehensive reporting workspace.

I designed a persistent navigation sidebar to search, organize, and reload saved reports, along with state restoration logic to remember applied filters and column selections. To prevent lost work, I built a multi-stage draft lifecycle that creates temporary drafts when query parameters change, giving users the option to inspect the results and either apply updates back to the parent report or branch them off into a new report.

As reporting needs expanded, I added a grouping architecture to organize related reports under shared operational categories. This included building batch execution logic to run all reports within a group simultaneously and creating unified group dashboards with global filters for shared date ranges and participant criteria.

Engineering with Production Discipline

Working long-term on CountBubble reinforced the practical side of software engineering:

Respecting legacy patterns, understanding why dependency upgrades can be dangerous in live systems, optimizing serverless execution times, and refactoring frontend code cleanly when new features require it. The result was a significantly expanded reporting tool delivered to active nonprofit users without causing regressions to core platform workflows.