Filomena — A health-sciences exam platform five institutions run on

Health-sciences degrees assess students through large, high-stakes written exams. Filomena's first version was a CakePHP and jQuery monolith built for a single institution, and it was showing every symptom of that: it degraded under concurrent load, exam delivery was sequential, access control was enforced inconsistently, and adding an institution meant writing code.

There was no monitoring, so problems surfaced as reports from people sitting an exam. For an application where a slow response during a timed assessment is an academic problem and not just a technical one, that was the constraint that mattered most.

Three roles with genuinely different needs. Administrators configure institutions, courses and schedules. Evaluators author questions and review results. Students sit the exams — and must remain anonymous to the evaluator grading them.

Those roles are not mutually exclusive. A professor can be an evaluator in one course and an administrator in another, which is why role handling had to be multi-role from the start rather than a single field on a user.

Filomena was built by a three-person team as our final year project at Universidad Nacional del Sur, and the product is a team achievement. I was the principal author and contributor: architecture, backend, frontend, infrastructure, security, observability, and coordinating the work.

I say principal contributor rather than sole author deliberately. The public repositories are a snapshot published as portfolio evidence — they are not a commit history that proves who wrote which line, and I would not present them as one.

Rather than refactor inside the monolith, we separated it into a Laravel REST API and a Next.js, React and TypeScript frontend. The decisive reason was not modernity: it was that a single API contract let us make the multi-institution model configuration rather than code, and gave concurrency a single place to be correct.

Performance work was concentrated where exams actually touch the system — question retrieval, session state, result submission. SQL tuning and index design came first, Redis caching second, and anything that did not need to happen during the request, such as generating result reports, was pushed onto a queue.

Agile practices with Trello, from requirements through to production. Three people, an academic deadline, and real institutions already depending on the previous version — so the work was ordered by what would break first, not by what was most interesting.

Deployments ran on Docker images built through GitHub Actions, observed at under fifteen minutes end to end. The public repositories are published snapshots and do not include that pipeline configuration.

Filomena is active at five Argentine national institutions: UNS, UNRN, UNC, UNVM and FAMFyG. It handled 1,000+ simultaneous users in production with complete data consistency, and kept critical endpoints below 300 ms on average.

These figures come from deployed operation, not from a benchmark harness in the repository. The project was graded 10/10 as a final year project at Universidad Nacional del Sur, and received interviews, university coverage and mentions from academic authorities — editorial recognition rather than a formally named award.

The test suite is the honest weak point. We validated behaviour through deployed operation and load validation, and the public snapshots ship framework smoke tests rather than a real suite. On a system where a defect interrupts an exam in progress, the concurrency and permission paths deserved automated coverage, and building it under an academic deadline was the wrong tradeoff to make twice.

I would also have written down the measurement conditions at the time. The performance numbers are real, but reconstructing exactly how each was observed, months later, is harder than it should have been — and a figure you cannot qualify is a figure you should be careful about repeating.