Building and operating a multi-tenant weather SaaS platform
How I designed and operate Vienor as a production weather SaaS platform: multi-company authorization, scheduled weather ingestion, derived alerts, subscriptions and reliability controls around third-party data.
The system
Vienor monitors weather conditions at field level and turns forecast data into alerts and daily summaries. What began as a product problem quickly became a systems problem: multiple companies and fields, scheduled data ingestion, external providers, user-specific notifications, subscriptions and production infrastructure all need to stay consistent.
I designed and built the platform end to end and continue to operate it in production, including the application architecture, backend behavior, data model, integrations, deployment and reliability work.
Multi-tenant authorization
The platform supports users who can belong to more than one company, with roles such as owner, administrator, agronomist, operator and viewer. Tenant membership is stored independently from the user so permissions can be evaluated in the context of the active company.
The backend resolves the active tenant for each session and applies centralized capabilities and tenant-aware guards to fields, alerts, analytics, notifications, team management and billing. Switching companies also clears tenant-scoped client state and cancels stale requests so data from one company is not carried into another.
Weather data pipeline
Forecast data is collected on schedules from multiple weather providers and reused across forecasting, comparisons, alerts and summaries. Provider selection can vary by plan without coupling the rest of the application to a single upstream service.
The ingestion flow is designed to avoid unnecessary requests and writes. Fresh forecasts can be reused, provider responses are shared where possible, and persistence only records meaningful changes instead of rewriting identical snapshots.
Reliability around scheduled work
Scheduled jobs run in an environment where multiple application instances can exist, so a cron expression alone is not enough to guarantee that work runs once. PostgreSQL advisory locks provide non-blocking coordination, with acquisition and release kept on the same transactional connection.
The pipeline also uses freshness policies, retries, deduplication and circuit breakers. For example, rate-limit responses from an upstream weather provider temporarily open a circuit instead of repeatedly calling an already constrained API. These controls reduce duplicate work and make failures in external services less likely to cascade through the platform.
Notifications and derived alerts
Weather data is evaluated into field-specific conditions rather than exposed only as raw forecasts. Rules generate alerts such as frost, rain and sustained high humidity, while daily summaries provide a scheduled view of current conditions.
Notification delivery is tenant-aware and checks current membership and company preferences before sending. Deep links resolve the appropriate company context before opening their destination, keeping multi-company behavior consistent beyond the main dashboard.
Subscriptions and production infrastructure
Vienor includes trial and paid subscription flows with Mercado Pago, alongside plan-aware product behavior. Billing permissions are separated from general administration so company roles do not automatically imply the ability to manage subscriptions.
The web application and API are deployed independently, backed by PostgreSQL/Supabase and delivered through Vercel and Render. Docker and CI/CD support repeatable development and deployment, while production work includes monitoring failures, reducing unnecessary database and API usage, and hardening the system as real operational constraints appear.
What this project demonstrates
The most important part of Vienor is not a particular framework. It is owning a production system across boundaries: authorization, relational data, scheduled jobs, external APIs, payments, frontend state, infrastructure and failure handling.
It reflects the kind of engineering work I prefer: understand the system, keep the architecture explicit, add reliability where failures actually occur and remain responsible for the software after deployment.
Related technical writing
Technical deep dives into architecture and implementation decisions used in this project.