The problem
A lot of small departments and institutions are still tracking their students out of spreadsheets, email threads, and the occasional shared Google Doc. It works — until it doesn't. Students slip through the cracks, marketing emails go out as bulk-blasts, and the data that could tell you what's working never gets aggregated anywhere useful.
I wanted to build something that a non-engineering team could adopt without an IT department's worth of effort — and that would still be flexible enough to grow with them.
What it does
- Centralized student records — a single record per student, with a full timeline of touchpoints.
- Tailored email campaigns — pull a segment, plug it into a template, send. The system handles personalization automatically.
- AI summaries — short, plain-language summaries of each student's engagement, surfaced so advisors don't have to read through years of notes.
- Lightweight CRM features — task assignment, follow-up reminders, and shared notes.
How it's built
The stack is intentionally boring: PHP on the server, MySQL for storage, and vanilla JavaScript on the front-end with a sprinkle of jQuery for legacy compatibility. The AI layer is a thin wrapper that calls into a model API for summarization — the prompts and outputs are stored in the DB so behavior is auditable.
The interesting design decisions were almost never about the framework. They were about what to not let the admin user do.
Things I learned
A working CRM-style product lives or dies by its data model, not by its UI polish. I rewrote the schema three times before I was happy with it — and the third version was the simplest. The first thing any new feature did was ask "does this fit cleanly into the existing tables?" If the answer was no, the feature usually wasn't worth shipping.
Where it goes next
I'm slowly opening it up as a self-hostable package so small departments can run their own copy. The hard part isn't the code — it's writing setup docs that don't assume someone already knows how to spin up a LAMP server.