Desarrollo y operación de una plataforma SaaS meteorológica multiempresa
Cómo diseñé y opero Vienor como plataforma SaaS meteorológica en producción: autorización multiempresa, ingesta meteorológica programada, alertas derivadas, suscripciones y controles de confiabilidad alrededor de datos de terceros.
El sistema
Vienor monitorea condiciones meteorológicas a nivel de campo y convierte datos de pronóstico en alertas y resúmenes diarios. Lo que empezó como un problema de producto se convirtió rápidamente en un problema de sistemas: múltiples empresas y campos, ingesta programada de datos, proveedores externos, notificaciones por usuario, suscripciones e infraestructura de producción tienen que mantenerse consistentes.
Diseñé y desarrollé la plataforma de punta a punta y continúo operándola en producción, incluyendo la arquitectura de la aplicación, el comportamiento del backend, el modelo de datos, las integraciones, el despliegue y el trabajo de confiabilidad.
Autorización multiempresa
La plataforma admite usuarios que pueden pertenecer a más de una empresa, con roles como propietario, administrador, agrónomo, operador y visualizador. La membresía se almacena de forma independiente del usuario para que los permisos se evalúen en el contexto de la empresa activa.
El backend resuelve el tenant activo en cada sesión y aplica capacidades centralizadas y guardias conscientes del tenant a campos, alertas, analítica, notificaciones, gestión de equipo y facturación. Al cambiar de empresa también se limpia el estado del cliente asociado al tenant y se cancelan requests obsoletos para evitar arrastrar datos de una empresa a otra.
Pipeline de datos meteorológicos
Los pronósticos se obtienen de múltiples proveedores en procesos programados y se reutilizan para pronósticos, comparaciones, alertas y resúmenes. La selección de proveedores puede variar según el plan sin acoplar el resto de la aplicación a un único servicio externo.
El flujo de ingesta busca evitar requests y escrituras innecesarias. Los pronósticos vigentes pueden reutilizarse, las respuestas de proveedores se comparten cuando es posible y la persistencia registra cambios significativos en lugar de reescribir snapshots idénticos.
Confiabilidad de los procesos programados
Los jobs programados corren en un entorno donde pueden existir varias instancias de la aplicación, por lo que una expresión cron no alcanza para garantizar que un trabajo se ejecute una sola vez. Los advisory locks de PostgreSQL coordinan las ejecuciones sin bloquear, manteniendo la adquisición y liberación sobre la misma conexión transaccional.
El pipeline también usa políticas de vigencia, reintentos, deduplicación y circuit breakers. Por ejemplo, cuando un proveedor meteorológico responde con límites de uso, el circuito se abre temporalmente en lugar de seguir llamando a una API ya restringida. Estos controles reducen trabajo duplicado y evitan que fallas de servicios externos se propaguen por la plataforma.
Notificaciones y alertas derivadas
Los datos meteorológicos se evalúan para obtener condiciones específicas de cada campo en lugar de mostrarse solamente como pronósticos crudos. Las reglas generan alertas como heladas, lluvia y humedad alta sostenida, mientras que los resúmenes diarios ofrecen una vista programada de las condiciones actuales.
La entrega de notificaciones tiene en cuenta el tenant y valida la membresía vigente y las preferencias de la empresa antes de enviar. Los deep links resuelven el contexto de empresa correcto antes de abrir el destino, manteniendo el comportamiento multiempresa también fuera del dashboard principal.
Suscripciones e infraestructura de producción
Vienor incluye flujos de prueba y suscripción paga con Mercado Pago, junto con comportamiento del producto según el plan. Los permisos de facturación están separados de la administración general para que un rol administrativo no implique automáticamente poder gestionar suscripciones.
La aplicación web y la API se despliegan de forma independiente, con PostgreSQL/Supabase como base de datos y Vercel y Render para la entrega. Docker y CI/CD permiten entornos y despliegues repetibles, mientras que el trabajo de producción incluye investigar fallas, reducir uso innecesario de base de datos y APIs y endurecer el sistema a medida que aparecen restricciones operativas reales.
Qué demuestra este proyecto
La parte más importante de Vienor no es un framework particular. Es hacerse cargo de un sistema en producción a través de distintos límites: autorización, datos relacionales, jobs programados, APIs externas, pagos, estado del frontend, infraestructura y manejo de fallas.
Representa el tipo de trabajo de ingeniería que prefiero: entender el sistema, mantener explícita la arquitectura, agregar confiabilidad donde realmente ocurren las fallas y seguir siendo responsable del software después del despliegue.
Artículos técnicos relacionados
Profundizaciones técnicas sobre decisiones de arquitectura e implementación usadas en este proyecto.