Context
Durania was created during a three-month livestock industry hackathon in Durango and received an honorable mention. The challenge was to digitize sanitary and operational processes while helping producers understand the location and condition of their cattle.
The result is a completed prototype, not a deployed government platform or certified monitoring device.
The operational problem
Many procedures still happen on paper. Completion is slow, information is fragmented and government, veterinarians, producers and operational staff do not share one system.
Field visibility creates an additional constraint: every collar cannot depend on a direct internet connection.
Actors and boundaries
Durania separates a public interface, an administration panel, a producer panel and an MVZ panel. Each actor has different journeys, responsibilities and data access.
The most important architectural question was how users, organizations and records would remain isolated at both database and application levels without making the design inaccessible to a collaborative hackathon team.
Solution
The prototype combines sanitary and operational workflows with tenant-aware storage and field telemetry. It supports government, veterinary and producer perspectives without collapsing them into one generic dashboard.
Product flow
- A public or administrative process creates shared operational context.
- Authorized MVZ and producer roles interact through their dedicated views.
- Collar nodes collect prototype location and temperature signals.
- A Raspberry Pi gateway forwards field information to backend ingestion.
- Tenant-aware storage makes the correct data available to authorized interfaces.
Architecture
The codebase follows an adapted semi-hexagonal structure across application, core, modules, server and shared concerns.
Next.js and TypeScript support the application, with Supabase, PostgreSQL and Prisma for data. Documentation, migrations, scripts and Vitest tests make the shared development process explicit.
IoT flow
Prototype ESP32 collar nodes act as field devices. A Raspberry Pi works as the local antenna or gateway and forwards location and temperature information. This reduces the need for every collar to maintain direct internet access.
The prototype does not claim certified sensor accuracy, medical use or field validation beyond its current scope.
Key technical decisions
- Enforce tenant separation in the data model and application responsibilities.
- Give each actor a dedicated interface instead of overloading a universal panel.
- Use a field gateway to aggregate local collar communication.
- Keep business modules separate while preserving a structure the collaborative team can understand.
- Document commits, migrations and responsibility boundaries as part of the architecture.
My contribution
I served as the technical architect. I designed the database, selected the technology stack, defined development practices, divided system responsibilities and coordinated technical tasks. I also implemented parts of the backend and frontend.
The project was a team effort. My responsibility centered on architecture, data, multi-tenancy, migrations, panel boundaries, documentation and technical planning.
Main challenge
Secure multi-tenancy was the deepest challenge. Actor boundaries also evolved during the project, forcing repeated UX changes when permissions and journeys had not been explicit enough at the beginning.
Outcome and current state
Durania is a completed hackathon prototype and received an honorable mention in 2026. It demonstrates a coherent multi-tenant and IoT direction; it does not claim production deployment or certified hardware.
What I learned
Durania was my first deep implementation of multi-tenant user and data design. It reinforced the importance of defining actors before interface and system responsibilities expand.
What I would change
I would define the limits, permissions and journey of every actor earlier. Those decisions should guide both data ownership and UX from the start.
Roadmap
Possible evolution includes offline field flows, hardware validation, aggregate government views, producer decision tools and carefully evaluated predictive indicators.
Interface gallery
The final gallery requires the administration, MVZ and producer panels, telemetry, the collar or gateway prototype and evidence of the honorable mention.
Demo walkthrough
The recorded demo presents the completed prototype and complements this case study with a direct walkthrough of the product and its different usage contexts.
Source
The repository is public and available through the verified source link provided in this case study.