CAP RMS

A case management system built for Community Action Programs. Three builds. Now available as a SaaS product.

The problem

Community Action Programs run on grants. Every grant has reporting requirements. Every reporting format is slightly different. The underlying data — who was served, their demographics, what services they received — is mostly the same across programs, just sliced differently.

Without a system designed for this, staff end up entering overlapping data into separate forms for separate grants. At reporting time, someone assembles reports manually, reconciling across sources. It's slow, it's error-prone, and it depends entirely on whoever happens to know where everything lives.

Generic CRMs can store the data. They can't solve the structural problem: one set of data, many reporting formats.

What was built

CAP RMS — Community Action Program Relationship Management System. Shane built the original system while working at a nonprofit, then rebuilt it with Claude Code as a standalone SaaS offering.

The core design: collect each data point once, at intake. When Grant Program A needs a report, the system pulls the relevant fields and compiles them in that program's format. Grant Program B gets the same underlying data packaged differently. Adding a new grant program means defining its format, not re-collecting its data.

Three builds total over roughly 2.5 years of active development:

• Initial demographics and reporting system
• Case management layer — case notes, follow-ups, interaction logs, the Self-Sufficiency Matrix (21 dimensions scored 1-5, tracked over time per participant)
• Full rebuild in a modern stack

The case management piece is where it got complex. Multi-agency data sharing with strict permissions. Signed authorization forms controlling who sees what. Case manager transitions where cases transfer without data loss. Cross-agency referrals from a public-facing link into a private database.

Shane maintained the legacy system in full production while building the replacement. No downtime. No disruption to daily operations.

He did all the requirements work himself — direct conversations with staff and management about how the workflow actually ran. He handled all user training. He evaluated an external vendor the organization brought in: that vendor took six months to deliver while billing for twelve. Shane built a more capable replacement in the remaining six months at no additional cost.

Where it is now

Rebuilt using Claude Code and available as a SaaS offering for today's Community Action Programs with current reporting requirements.

What this demonstrates

Real organizational complexity, handled. Nonprofit grant reporting has overlapping, conflicting requirements. Building a system that does it right required understanding how the organization actually worked, not just what they asked for.

Requirements work at scale. Shane talked to the people using the system. He watched what they did. He built what they needed, which was frequently different from what they initially described.

The vendor comparison. An external vendor took twice as long, cost more, and delivered less. Shane built the replacement for free in half the time. That's not a brag — it's a concrete illustration of what happens when the person building the system actually understands the business.

Transferable architecture. Collect data once, report many ways, complex permissions, case-based workflows. That pattern applies to property management, professional services, contractor tracking, and any business managing ongoing relationships with structured data.