tools / record
ASEP STELLAR Educator Dashboard
▶ Guided tour — asep-tour.eponymic.org — a simulated walkthrough. The live platform holds real educator data and isn’t publicly linked.
I designed, built, and maintain the STELLAR Educator Dashboard for ASEP, a Texas education-research nonprofit — as the sole technical operator, from architecture and data model through deployment and ongoing operations. It collects STELLAR-framework survey responses from public-school educators across Texas and gives each of them a personal dashboard: their own scores, how their district benchmarks, and where their priorities rank.
The real specification was trust
An educator will not answer honestly about where they feel valued if they suspect their principal or district can read the answer. So the actual product isn’t the charts — it’s a credible, enforced promise that an individual’s responses belong to that individual alone. If that promise is soft, two things happen: the data becomes worthless, and a real person can be harmed by it. Every consequential decision on this project traced back to that single constraint.
What I built
A full-stack TypeScript application, end to end:
- Frontend — React 19, Tailwind CSS 4, shadcn/ui, Recharts for the score and benchmark visualizations.
- Backend — Express + tRPC for type-safe endpoints, PostgreSQL (Neon) via Drizzle ORM, Zod validation throughout.
- Auth & platform — Clerk (Google SSO + magic link), deployed on Railway at a custom domain, with transactional email and a feature-flagged SMS opt-in built to be TCPA-compliant before it’s ever switched on.
The educator flow runs survey → personalized dashboard; a separate administrator surface handles district-level views, and a provisional-access path lets someone start before their district affiliation is verified.
The trust architecture — where the work actually was
- Individual scores are structurally private from principals and districts, and the educator is told so in plain language at the moment of consent — the promise is made where the hesitation lives, not buried in a policy page.
- Re-identification is treated as a live threat, not a checkbox. In a small district, an “anonymous” aggregate can still fingerprint one person, so demographic and benchmark breakdowns are suppressed below a minimum respondent count rather than shown because the query technically returns.
- The data lifecycle is minimizing by design. Provisional sign-ups expire and are wiped if a district affiliation isn’t verified, so the system holds only the data it has a reason to hold.
- The paid boundary never charges the individual. Districts pay for aggregate views; educators are never the product — which keeps the incentive structure aligned with the privacy promise instead of against it.
- Auth and secrets were hardened deliberately — attack protection tightened, no secrets in the tree — because a trust product loses everything the first time that claim fails.
What it taught me
A platform that holds sensitive data about identifiable people is judged less by what it can do than by whether it is unambiguous about whose side it is on. Almost every real decision here came down to closing the distance between what the system promised and what it could actually guarantee — and noticing where those two diverge.
Walk through it: asep-tour.eponymic.org