PATAgenda
Teacher disciplinary case agenda
paper and Excel with no traceability.
web system with zero missed deadlines
"Development of a full-stack agenda that accurately models the legal language of the Ministry of Education while prioritizing sensitive data privacy."
The starting point of the challenge
Digging beneath the surface: What did I investigate?
I thoroughly analyzed the client's daily workflow over several weeks. I discovered that most task managers assume linear, abstract flows like "to-do," "in progress," "done." But a disciplinary case follows a regulated lifecycle with specific legal statuses and hard deadlines that, if missed, have real legal consequences. It's not a Kanban board. It's a calendar of legal obligations. I evaluated infrastructure options: cloud services like Firebase or Supabase would have accelerated development, but they meant storing disciplinary data on third-party servers. The solution had to be deployable but with restricted, controlled access.
"Software adoption doesn't fail for technical reasons. It fails when the system doesn't represent the user's way of thinking. The data model had to speak the language of the Ministry of Education precisely. Instead of modeling abstract statuses like "pending" or "completed," I designed real legal domain concepts: Ordinary Disciplinary Proceeding, Abbreviated Proceeding, Mediation, Dismissal, Serious Sanction, each with its own deadlines, expiration dates, and specific restrictions. Designing for a single user was also liberating: it eliminated the need to manage complex roles or concurrent access and allowed focusing all energy on polishing a product that genuinely works for her."
Understanding this pillar completely transformed the tactical direction of the project, allowing unnecessary noise to be filtered out and focusing on strict value.
Tradeoff Analysis: options on the table
Building custom software requires honestly evaluating scenarios. No architecture is perfect — every decision has a price:
Generic cloud managers (Notion, Trello)
Quick to set up and no development needed. But it violated privacy requirements by storing sensitive data on third-party servers, and forced the client to adapt complex legal processes to generic abstractions that don't represent her reality.
Custom cloud system (Supabase, Firebase)
Lower infrastructure complexity and automated backups. But it meant storing confidential disciplinary information about teachers on external servers, which was unacceptable from both a regulatory and ethical standpoint, regardless of the provider's security promises.
Self-hosted full-stack application
This was the original plan. Data would reside exclusively on the local device under the client's direct control, with zero SaaS costs. But the downside was losing remote access and mobility: she could only use the system from that computer. We ultimately opted to deploy on Vercel for flexibility.
Single-user design without concurrency
Radically simplified the architecture by eliminating roles, permissions, write locks, and editing conflicts. It allowed focusing all effort on polishing the experience for one specific user. But it rigidified the model: scaling to multiple inspectors would require deep structural changes.
JWT httpOnly + rate limiting security
Storing the token in an httpOnly cookie, inaccessible from JavaScript, mitigated XSS risk. Rate limiting prevented abuse. OAuth or two-factor authentication wasn't implemented because, for a local single-user application, it would have been over-engineering with no real security benefit.
The Decision: The path chosen
WHAT ACTUALLY WORKED
What worked best was that the system spoke the client's exact language from day one: there was no need to translate legal domain concepts into software abstractions, and no forced learning curve. The dispersion of information — her greatest daily pain — collapsed into a single place, and phone access covered the out-of-office case that kept falling through. The client still uses it as her working system.
LIMITATIONS & TRADE-OFFS
Being deployed in the cloud, sensitive data no longer resides exclusively on the client's device, although access is restricted by authentication and connections are over HTTPS. PostgreSQL and Vercel hosting have a monthly cost that didn't exist before. Depending on an internet connection means the system becomes inaccessible during network outages. The application is modeled for a single person; scaling it to a team of inspectors would require deeply restructuring the data model and permission management.
FROM GONZALO'S PERSONAL LOGBOOK: WHAT WOULD I DO DIFFERENTLY TODAY?
"I would implement automated PostgreSQL backups to have security copies without depending on manual processes."
Retrospective note after launch