Plataforma de trámites de movilidad

Contexto y frontera de autoría

Me incorporé a una plataforma que ya estaba en desarrollo. Durante mi participación entre 2025 y 2026 trabajé como desarrollador Full Stack y asumí el liderazgo técnico aproximadamente desde la mitad del proyecto.

Esa secuencia importa: no presento como propias la creación inicial del producto, las decisiones anteriores a mi incorporación ni el trabajo completo del equipo. El caso explica las responsabilidades que asumí y las decisiones en las que participé directamente.

Problema técnico

La plataforma debía coordinar trámites compuestos por formularios, documentos, revisiones y cambios de estado. Cada operación ocurría dentro de un contexto de roles y reglas administrativas, por lo que un cambio aislado en la interfaz o en la persistencia podía afectar el seguimiento completo de una solicitud.

El reto no era únicamente construir pantallas. Había que conservar la relación entre lo capturado, la etapa vigente, las decisiones de revisión y el historial necesario para explicar qué había cambiado.

Responsabilidad y liderazgo

Mi responsabilidad incluyó arquitectura, administración y diseño de base de datos, revisión y auditoría de código, organización del desarrollo y coordinación de un equipo de cinco integrantes. También impartí capacitación técnica para compartir criterios del proyecto y reducir diferencias entre implementaciones.

El liderazgo no sustituyó el trabajo Full Stack: seguí participando en cambios de backend, datos e interfaces mientras coordinaba requerimientos y revisiones.

Restricciones

• La autenticación, los roles y los flujos administrativos existentes debían conservarse mientras evolucionaban los módulos.
• Backend, base de datos y frontend avanzaban sobre un producto en curso.
• Los contratos debían sostener formularios y procesos configurables sin dispersar reglas entre pantallas.
• Los nombres institucionales, endpoints, datos y procedimientos internos no forman parte de este caso público.

Arquitectura publicable

El backend usa ASP.NET Core y separa responsabilidades de aplicación, dominio e infraestructura. EF Core y PostgreSQL sostienen la persistencia de entidades, catálogos y relaciones que participan en los flujos de trámite.

El frontend usa Vue 3 y TypeScript. Los módulos distinguen acceso a datos, reglas de dominio y componentes de interfaz; Quasar, Pinia y Vue Router resuelven la composición visual, el estado y la navegación.

La figura asociada representa únicamente esas fronteras conceptuales. No es un mapa de infraestructura, una copia de componentes privados ni una descripción de la topología de despliegue.

Decisiones relevantes

Seguir el recorrido completo

Los cambios se revisaban desde la captura hasta la persistencia y el seguimiento. Esto permitió tratar contratos, reglas y visualización como partes del mismo recorrido sin convertir el producto en una colección de pantallas independientes.

Hacer explícitas las fronteras

En backend, los casos de uso y las reglas de dominio se mantuvieron separados del acceso a datos. En frontend, el acceso a API, el comportamiento del dominio y los componentes visuales conservaron responsabilidades distintas. La separación facilitó localizar el impacto de un cambio transversal.

Reutilizar comportamiento verificable

Formularios, tablas y paginación se trataron como piezas reutilizables cuando compartían contratos y comportamiento. La coincidencia visual, por sí sola, no era suficiente para crear una abstracción.

Incorporar revisión y capacitación

La revisión de requerimientos, contratos y código se utilizó para detectar responsabilidades duplicadas y cambios con impacto transversal antes de integrarlos. La capacitación técnica complementó esa revisión: el objetivo era compartir criterios, no centralizar cada decisión en una sola persona.

Resultado verificable

Durante mi periodo quedaron una base modular para trámites, formularios, documentos y etapas de revisión; componentes reutilizables para captura, consulta y seguimiento; y decisiones técnicas documentadas para coordinar cambios entre backend y frontend.

También puedo respaldar la coordinación del equipo de cinco integrantes y la capacitación impartida. Son responsabilidades de mi periodo, no una atribución del producto completo.

Límites de evidencia

El caso describe únicamente mi periodo y las responsabilidades que puedo respaldar. No incluye nombres institucionales, datos, endpoints, capturas, credenciales, estado posterior del producto ni trabajo atribuible a otras personas. Tampoco publica métricas, adopción, estado de producción ni resultados operativos porque no existe evidencia pública suficiente para sostenerlos.

Aprendizaje

Asumir liderazgo en un producto existente exige separar lo heredado de las decisiones propias y sostener esa frontera en cada revisión. La trazabilidad técnica sigue el mismo principio: registrar qué cambió, por qué y qué partes afecta permite coordinar mejor que una abstracción aplicada de forma uniforme.