SaansBudget: Turning Air Quality Data into Everyday Decisions
What if an air-quality app could do more than display AQI? Explore the architecture behind SaansBudget, a pollution-aware planning platform designed to compare routes, estimate exposure, and turn environmental data into practical decisions using cloud technologies.
B.Tech @PICT | GSSoC ’26 Contributor | Backend Developer | MERN Stack | Docker | 1x Hackathon Winner
SaansBudget: Turning Air Quality Data into Everyday Decisions
Air pollution is often communicated through a single number: the Air Quality Index (AQI). While AQI helps people understand general air-quality conditions, it doesn't necessarily answer the questions they face every day.
Should I leave for college earlier? Could an alternative route have lower estimated pollution exposure? How should changing weather conditions affect my outdoor plans?
These questions inspired SaansBudget, a pollution-aware planning platform designed to transform environmental data into more actionable everyday guidance.
Rather than building another AQI dashboard, I wanted to explore how a full-stack application could combine air-quality observations, weather forecasts, route information, and cloud infrastructure to help people make more informed decisions.
The Problem: AQI Alone Is Not the Whole Story
Two journeys can take different amounts of time and pass through areas with different air-quality conditions. Similarly, the conditions experienced during a morning commute may differ from those later in the day.
A city-level AQI value does not capture all these differences.
SaansBudget aims to address this gap through four core capabilities:
- Pollution-aware route comparison: Compare journey options using available air-quality data and estimated travel times.
- Departure-time planning: Evaluate different departure windows using available forecast data.
- Exposure tracking: Summarize estimated pollution concentration over time to help users understand their daily travel patterns.
- Indoor-air guidance: Provide context-aware suggestions that consider available indoor and outdoor readings.
The intended audience includes students, commuters, outdoor workers, and families looking for practical ways to incorporate air-quality information into their daily routines.
Designing the Technical Architecture
I approached SaansBudget as a full-stack engineering project, with a focus on modularity, data provenance, and the ability to deploy components independently.
The planned application architecture consists of the following layers.
1. Frontend: React
The React frontend is designed to bring together maps, route comparisons, air-quality summaries, and historical exposure information.
The goal is to make the results understandable without requiring users to interpret raw environmental datasets themselves.
A route comparison, for example, should communicate not only which option has a lower estimated exposure proxy, but also the expected travel time, freshness of the data, and uncertainty involved.
2. Backend: Node.js and Express
The backend provides the application API and coordinates data retrieval, route calculations, and recommendation logic.
Keeping the calculation logic separate from the API routes makes it easier to test the underlying algorithms and change external data providers without redesigning the entire application.
The backend is intended to expose versioned REST endpoints for air-quality information, route comparisons, departure-time recommendations, and exposure history.
3. Data storage: PostgreSQL
SaansBudget needs to work with structured observations, timestamps, geographic coordinates, and user travel history.
PostgreSQL is a suitable choice for storing these relationships. PostGIS can extend the database with spatial queries if geographic filtering and proximity calculations become central to the implementation.
An important design consideration is preserving the source and timestamp of each observation. A measured value, a forecast, and an interpolated estimate are not interchangeable, even if they appear on the same map.
Estimating Exposure Without Overstating Accuracy
One of the most important engineering decisions is how to communicate exposure estimates responsibly.
For a route divided into segments, a simple concentration-time proxy can be calculated as:
Exposure proxy = Σ (Cᵢ × tᵢ)
Where:
- (C_i) is the estimated pollutant concentration for segment (i), expressed in micrograms per cubic metre (µg/m³).
- (t_i) is the estimated time spent in that segment, expressed in hours.
The resulting unit is µg·h/m³.
This metric can help compare journeys under stated assumptions. However, it is not a measurement of the user's inhaled dose, and it should not be presented as a medically validated daily exposure limit.
Actual inhaled dose depends on additional factors, including breathing rate and activity level. Route-level estimates also depend on the availability, freshness, and spatial resolution of environmental data.
For that reason, the platform should communicate uncertainty rather than imply that every street-level value is directly measured.
If a nearby observation is stale or the data coverage along a route is poor, the application should flag the limitation instead of silently treating missing values as zero.
Where AWS Fits Into the Design
AWS provides managed services that can support the deployment and operation of a data-driven application such as SaansBudget.
The proposed cloud architecture includes the following services:
AWS App Runner — Application hosting
App Runner is a candidate for hosting the Node.js and Express backend while reducing the need to manage servers directly.
Amazon RDS for PostgreSQL — Database
RDS can provide managed PostgreSQL infrastructure for structured environmental data, user preferences, and exposure history. Spatial functionality could be added through PostGIS where supported by the chosen database configuration.
AWS Lambda and Amazon EventBridge Scheduler — Data ingestion
Lambda functions can retrieve environmental data from external providers, normalize incoming records, and store validated observations. EventBridge Scheduler can trigger ingestion jobs at defined intervals.
The ingestion process should handle provider errors, rate limits, missing values, and duplicate records rather than assuming every request succeeds.
Amazon CloudWatch — Monitoring
CloudWatch can centralize application logs and help identify failed ingestion jobs, API errors, and operational issues.
The actual service selection should be guided by workload requirements, deployment complexity, and cost. A student project does not need every AWS service from the beginning.
Implementation note: These services describe the proposed architecture. A service should only be considered deployed and operational after it has been configured and tested in the project environment.
Data Sources and Reliability
The usefulness of SaansBudget depends heavily on the quality of its input data.
Potential sources include OpenAQ for available air-quality observations and Open-Meteo for weather and air-quality forecasts. Routing and geographic data can come from compatible mapping providers.
Each provider has its own coverage, update frequency, licensing conditions, and usage limits. Availability also varies by location and pollutant.
A reliable implementation should therefore:
- Preserve observation time and retrieval time separately.
- Identify whether a value is measured, forecast, or estimated.
- Handle stale data and unavailable providers explicitly.
- Avoid inventing readings when data is missing.
- Display meaningful confidence or coverage indicators.
- Respect the terms and rate limits of external data providers.
These safeguards are important because a polished interface cannot compensate for unreliable underlying data.
Engineering Challenges Worth Solving
Several challenges make this project more than a straightforward dashboard.
Comparing routes fairly: The shortest route is not necessarily the route with the lowest estimated concentration-time proxy. Users should be able to understand the trade-off between journey duration and estimated exposure.
Selecting a departure time: Forecasts must be evaluated across comparable time windows, accounting for estimated journey duration and forecast availability.
Communicating uncertainty: Estimates based on distant monitoring stations should not be displayed with the same apparent certainty as reliable nearby observations.
Keeping the system affordable: Managed cloud services simplify operations, but they can introduce costs even in relatively small applications. Resource selection, scheduled workloads, monitoring, and cleanup practices need to be considered from the beginning.
These are also opportunities to apply core software engineering practices: modular design, validation, error handling, automated tests, and clear API contracts.
What I Want SaansBudget to Achieve
The objective is not to promise pollution-free travel or provide medical advice. It is to make environmental information easier to interpret and use.
A useful application should help users compare available options, understand the assumptions behind its recommendations, and recognize when the underlying data is insufficient for a reliable comparison.
For me, SaansBudget is an opportunity to explore the intersection of full-stack development, geospatial data, environmental analytics, and cloud engineering through a problem that affects everyday life.
The broader lesson is simple: useful data products should do more than present information. They should help people understand their options, while being honest about what the data can and cannot tell them.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article