
From AQI Numbers to School-Day Decisions: Building SaansSchool
A school air-quality project that turns regional model estimates into practical, understandable plans for the people caring for students.
From AQI Numbers to School-Day Decisions: Building SaansSchool
An air-quality number can inform a school that conditions have changed. But what should they do about it? Should morning assembly move indoors? Physical training be cancelled? What should parents know?
I have built SaansSchool , a web application for school communities that makes sense of air-quality estimates, school-day plans, and parent communication.
The problem I wanted to address
is that most air dashboard displays give little guidance in making those decisions. A principal or teacher has to interpret an air quality index (AQI) for PM2.5 and PM10 particulate matter for their own context and audience.
That's a good thing. The value of a school air quality dashboard is in its ability to translate an estimate into information specific to the school's needs and circumstances. But that leaves educators with the challenge of understanding what the number means for their program and effectively communicating that to their community.
That's why I want to build SaansSchool : to help schools make the most of their air quality information by connecting it to their school-day planning and parent communication needs.
Turning data into a plan
SaansSchool uses Open-Meteo's Air Quality API , which provides PM2.5 and PM10 estimates derived from the Copernicus CAMS model. Using these values and breakpoints from the CPCB , SaansSchool calculates an estimated AQI and displays it alongside the underlying pollutant information. The Tomorrow's Plan section then uses the estimated AQI to help educators think through their options.
As a school planning tool, SAANSSCHOOL is intentionally non-prescriptive. It's up to the school to decide what level of air quality is acceptable for their activities and community.
A parent message based on conditions
SaansSchool can generate a draft parent message based on the estimated AQI. The preview is available in English and Hindi so that a school can review and understand the language and tone before sharing.
The public demo instance for this application is read-only: it cannot send emails, view parent records, or receive feedback. These capabilities are gated as they shouldn't be available in this context. This project's demo experience must balance the need to demonstrate features' value and avoid disclosing private parent and school data.
How it's built
This application was built with Next.js's App Router and TypeScript. The public dashboard, air quality views, plan, parent-message preview, and settings are organized in a shared responsive layout.
The backend is handled by Next.js route handlers for air quality and school data and SQLite for storing account, school, and alert records. The public demo instance connects to the same air quality API but not the school database: endpoints for records or modifications are either disabled or unavailable.
This separation made me consider the demo's safety as part of its design: a demo link shouldn't silently expose production records.
Thoughts on implementation
Recommendations need context
A single number is rarely informative. Context is critical in interpreting an AQI value and determining its impact on school activities. However, a school's informational resource should always be careful to distinguish between recommendations and medical advice.
A model estimate is not a school sensor
Schools can use a range of air quality information, from research-grade models to low-cost sensors. However, a dashboard displaying model-derived air quality values must make that distinction clear.
Communication is reviewable
Automated messages can be convenient, but they should always be reviewed for accuracy and appropriateness. A school can review the parent-message preview before sending to ensure it reflects their context and circumstances.
Lessons learned
When building this application, I learned that presenting data in context is often more valuable than displaying it. After all, the value of an air quality dashboard is often in its ability to inform decisions based on those numbers.
In addition, context is critical in choosing what to demonstrate in a public demo instance. While it should demonstrate features, it should not expose or endanger parent data.
What's next
The next steps for this project are to connect it to a long-term hosting environment with reliable storage and a production email-sending configuration. In addition, I will want to validate the recommended school activities with educators and improve the display of estimates' source, freshness, and uncertainty.
Comments: This project is not meant to be deployed as an AWS cloud solution. This application is built with Next.js, SQLite, and the Open-Meteo air quality API. If I were to host this application on AWS, I would describe the technical details in a separate post and documentation, considering the technical requirements of the application.
Try SaansSchool
- Demo video: Watch SaansSchool
Air-quality values are regional model estimates, not school-site sensor readings or official advisories. SaansSchool provides general school-planning guidance, not medical advice.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article