SANITIZED CASE STUDY
Sistema de Relevamiento Territorial
Frontend para una operación de campo realizada desde tablets y bajo condiciones de conectividad limitada.
Demo pública sanitizada y recortada del frontend original.
Contexto y problema
El sistema debía utilizarse durante una actividad de relevamiento territorial realizada en campo mediante tablets. La interfaz no podía pensarse solamente como una aplicación web de escritorio con conexión permanente: durante la operación podían existir interrupciones o degradaciones de conectividad y era necesario evitar que el trabajo realizado por el usuario se perdiera ante esas condiciones.
El frontend debía estar disponible en menos de un mes y preparado para una operación concreta. Las decisiones técnicas tenían que priorizar confiabilidad operativa, claridad de interacción y capacidad de entrega por encima de complejidad innecesaria.
La aplicación se integraba con una API desarrollada en paralelo al frontend y debía permitir avanzar durante el relevamiento manteniendo borradores y persistiendo información progresivamente a medida que las condiciones lo permitieran.
Experiencia de captura y flujo
El frontend se organizó alrededor del flujo real del relevamiento y de la captura de información desde tablets. La claridad de interacción debía acompañar el trabajo de campo, sin depender de condiciones ideales de red.
El análisis, el esquema y las decisiones de arquitectura fueron conjuntos. Mi aporte individual fue llevar ese trabajo a la interfaz y resolver el comportamiento del frontend necesario para la actividad prevista.
Con una ventana inferior a un mes, mantuve acotado el alcance: el objetivo no era construir una infraestructura frontend genérica, sino implementar de manera clara el recorrido necesario para la operación.
Mi responsabilidad y restricciones
Implementé individualmente el frontend en React y TypeScript, su integración con la API y el comportamiento de borradores y persistencia progresiva necesario para el uso desde tablets.
Otro integrante del equipo de desarrollo implementó el backend en paralelo al frontend. La implementación del backend y los componentes Android quedaron fuera de mi responsabilidad individual.
Las principales restricciones fueron el tiempo de entrega, el dispositivo objetivo y la posibilidad de conectividad limitada durante una actividad que no podía depender de una conexión permanente.
Borradores y persistencia progresiva
Una decisión central fue evitar que cada interacción se tratara como una operación que debía completarse inmediatamente contra el servidor. El estado del trabajo podía mantenerse mediante borradores y persistirse progresivamente a medida que las condiciones lo permitieran.
Esto reducía la dependencia de una conexión estable durante todo el proceso y el riesgo de perder información ya ingresada. La interfaz debía seguir siendo útil ante variaciones de conectividad.
Este alcance no implica una arquitectura offline-first ni una garantía de sincronización ante cualquier interrupción. La decisión respondía a las condiciones concretas del relevamiento y a la integración con la API desarrollada en paralelo.
Demo pública y límites
La demo pública sanitizada del relevamiento territorial permite recorrer parte del comportamiento del frontend con datos sintéticos, sin exponer información institucional ni dependencias privadas.
Es una versión recortada del frontend original: se omitieron o reemplazaron ramas del flujo, lógica, datos y detalles del contexto profesional real. La demo no equivale al sistema completo ni permite verificar por sí sola la operación original o su integración real con la API.
Su propósito es ofrecer evidencia pública de una parte de la interfaz y del recorrido de captura. La evidencia de uso en campo corresponde a la actividad profesional, no a esta demostración.
Validación y resultado
La validación principal no fue solamente técnica. El sistema fue utilizado en la actividad real para la que había sido desarrollado, durante una jornada de aproximadamente seis horas, desde los dispositivos previstos y bajo las condiciones operativas para las que se había diseñado.
La actividad pudo completarse y los datos producidos durante el relevamiento fueron posteriormente entregados. Ese uso permitió validar que el flujo era utilizable desde tablets y que las decisiones relacionadas con borradores y persistencia eran compatibles con el contexto de campo.
Las seis horas describen la duración de la actividad, no un SLA ni una medición de rendimiento. No atribuyo al sistema un impacto organizacional mayor que ese resultado concreto: el frontend fue entregado en el plazo requerido y utilizado para completar la operación prevista.
Qué demuestra
- Traducir restricciones operativas reales —tablets, trabajo de campo y conectividad limitada— en decisiones concretas de frontend.
- Implementar una interfaz en React y TypeScript e integrarla con la API desarrollada en paralelo.
- Resolver borradores y persistencia progresiva para reducir la dependencia de una conexión estable.
- Acotar el alcance y entregar en menos de un mes un frontend utilizado en una actividad real, no solamente en una demostración.
Tecnología y evidencia
Tecnología principal: React · TypeScript · Vite · integración REST · Git · CI/build · GitHub Pages para la demo sanitizada.
El proyecto utilizó un proceso automatizado de build mediante CI. La evidencia pública incluye la demo sanitizada, dos capturas sanitizadas y el diagrama conceptual derivado de la conservación progresiva del trabajo; la evidencia privada de operación pertenece al contexto profesional y no se publica en este caso.
Nota de privacidad
SANITIZED CASE STUDY
El sistema original pertenece a un contexto profesional. Nombres, datos, endpoints, capturas y otros detalles internos fueron omitidos o reemplazados para evitar exponer información institucional.