For a while, running P² Edu-tech meant juggling three different tabs that never talked to each other. Leads lived in one spreadsheet. Student progress lived in another. Batch feedback lived in a third. A prospect would sign up, become a student, finish the course, and by the time we looked back at “why did this person join us,” that context was just… gone. Nobody wrote it down anywhere that mattered.
So I built a dashboard that treats a student’s whole journey as one thread instead of three separate files that don’t know about each other.
What it actually does
There are three parts, and they map exactly to how a student moves through our program:
• Lead Tracker – a Kanban board, follows someone from “just filled a form” all the way to “enrolled”
• Student Progress – tracks attendance, practicals, and project milestones once they’re in
• Batch Improvement Log – compares feedback across different cohorts so we can actually see what’s working and what isn’t
None of these three ideas are new on their own. What makes it useful is that they all pull from the same memory layer, built on Hindsight, so nothing gets dropped at the points where a lead turns into a student, or a student turns into “someone we’re now reporting on.”
The Kanban board (leads)
If you’ve used Trello, you already get this. Cards move left to right through columns as a lead progresses — New, Contacted, Qualified, Demo Scheduled, Enrolled.
Right now we’ve got 6 leads in the pipeline worth ₹295K, with 1 already enrolled. Each card shows which course they’re interested in, who’s following up with them, and how many notes have been logged on them.
Honestly the board itself wasn’t the hard part — that’s a weekend project. The part that mattered was making sure the follow-up history didn’t just vanish once a lead became a student. Every note, every call log, every “they mentioned they’re worried about the pace of the course” — that stuff used to just sit in a closed lead record and rot. Now it stays alive as memory that the Student Progress module can actually pull from later.
*Student Progress
*
Once someone enrolls, they show up here instead. This is where mentors check in on attendance, practicals, and how far along someone is on their capstone project.
We’re tracking 10 students right now, average progress sitting at 67%. You can filter by batch, which matters a lot for us since we run a few cohorts in parallel and mentors mostly only care about their own group. Kabir’s at 45% and flagged “At Risk” — that’s the kind of thing this view is supposed to surface early, before it becomes a “why didn’t anyone catch this” conversation at the end of the course.
This is also where the memory layer quietly does its job. Every time a mentor opens a module, that gets logged. Not every click — just which parts of the system people actually look at, and how often. Over a semester that turns into something genuinely useful: not “did the student log in,” but “did the humans responsible for them actually check on them.”
Batch Improvement Log
This is the module I wasn’t sure would be worth building, and it turned out to be my favorite one.
It takes feedback from every batch, buckets it by category (Course Content, Instructor Quality, Practical Sessions, Project Support, Materials), and lets you compare cohorts side by side. Batch 2024-A finished at 4.5/5 average feedback with 86% satisfaction. Batch 2024-B is still ongoing, sitting at 4.3/5 and 79% satisfaction. That gap is small, but it’s the kind of gap you’d never notice just eyeballing individual feedback forms one at a time.
What makes it actually useful for us, and not just a chart, is that it’s pulling from the same memory the other two modules use. So if a mentor asks “did we already know Batch B was going to struggle with practical sessions,” the answer isn’t “let me go dig through forty feedback forms.” It’s already connected.
The memory badge
You’ve probably noticed it in every screenshot — top right corner, small green pill that says “Memory layer active.”
I added this on purpose, not just for decoration. I wanted our team to actually see when the memory system was live, instead of just trusting a README that says “yes it’s connected, promise.” Once people could see it was really running, they stopped re-typing context they’d already logged somewhere else in the system. That trust is honestly most of the value.
If you’re building something similar — anything where a person or record moves through stages with different people responsible at each stage — I’d genuinely recommend building the memory in from day one instead of bolting it on later. You can poke around Hindsight on GitHub or check the docs if you want to see how it fits together.
Top comments (0)