Petucho
ESStart a projectStart

Case study · Institutional platform

Teacher evaluations, made anonymous.

SED is the evaluation system for a public university in Mexico: students, teachers, and staff evaluate teaching performance every term without storing a link between a response and a person's identity.

Django + DRFReact 19PostgreSQLRedis + CeleryDocker / AWS

Open the live system

Live SED landing page with two entries: evaluate teachers, or open the admin panel.
Live landing on the current deployment. Two audiences, one system.
Respondent screen: enter an institutional access code to start an anonymous evaluation.
Respondent entry. One opaque code. No account.

By construction

How anonymity is built

The respondent never creates an account. The file that remains cannot be edited.

  1. 01Token

    The server issues a credential without a name.

  2. 02Session

    The respondent redeems it once without creating an account.

  3. 03File

    The answer is written. Then it cannot change.

The problem

The university's previous evaluation system was a legacy stack with a fundamental trust problem: respondents could not be sure their answers were anonymous, so participation and honesty suffered. The new system had to guarantee anonymity by construction, survive real term-end traffic, and produce reports administrators could audit.

What I built

A full-stack platform with two separate sides: an admin console for catalogs, teaching assignments, survey instruments, credentials, and analytics, plus a respondent flow that works with a single opaque credential and leaves no identifying trail.

Coordinator dashboard with period metrics, category averages, and academy results.
Coordinator dashboard. Burner period data from a local capture.
Instrument management screen with a 360 evaluation package and create-instrument actions.
Survey instruments and 360 packages. Burner labels left visible.
  • Opaque credential system: respondents redeem a server-issued token for an anonymous session. No name, no account, no way to link a response to a person.
  • Immutable submissions: once an evaluation is submitted it cannot be edited or deleted. The dataset the institution reports on remains the dataset that was collected.
  • Survey engine: configurable instruments with matrix questions, Likert scales, open text, theory/practical classification questions. Each instrument follows a strict lifecycle: draft → published → closed, with soft-deletes instead of hard erasure.
  • Analytics & reports: per-professor and per-unit reports for institutional decision-making.

Engineering standards

The project has checks at each stage of development and release:

  • 1,750+ backend tests and 830+ frontend tests, run in CI on every change.
  • Strict bundle budgets: every JavaScript chunk is measured and capped for slower devices and campus Wi-Fi.
  • Ongoing security review: authentication boundaries, sessions, and data storage are reviewed throughout development. Findings are tracked until they are resolved.
  • Observability built in: health checks, request tracing, and metrics wired to monitoring from day one.
  • Reproducible deployment: Docker images built in CI, promoted through environments, released to AWS with an audited pipeline.
The requirement was never just "collect evaluations." It was: prove to thousands of students that their voice is safe.

Result

The institution can use the platform for each evaluation period. The respondent flow does not collect a person's identity, submitted evaluations cannot be changed, and automated tests protect the main workflows. Architecture documentation gives new engineers a place to start without relying on an oral handover.

The current deployment is live at98.95.232.141.sslip.io/. Admin and evaluation entry require institutional credentials.

Building software that handles sensitive data?

Tell me what the system must protect and how people will use it.

Talk about your project