From Air Quality Forecasts to School Decisions: Building Airwise on AWS
How I built and deployed Airwise, an AI-powered school air-quality planning dashboard, during Environmental Hacks 2026. This hands-on case study covers the serverless AWS architecture, automated forecast ingestion, activity scheduling logic, and Amazon Bedrock integration that turns air-quality forecasts into actionable explanations for school administrators.
From Air Quality Forecasts to School Decisions: Building Airwise on AWS
How I designed, built, and deployed an AI-powered school air-quality planning dashboard during Environmental Hacks 2026.
Air pollution is often presented as a number. You open a dashboard, see a PM2.5 reading, and learn that air quality is poor. But for a school administrator, that number leads to a more practical question:
Should morning assembly happen outside today? What about sports practice? Is there a better time to schedule an outdoor activity?
I built Airwise — School Air Quality Intelligence to explore that problem during Environmental Hacks 2026, organised by WeMakeDevs in collaboration with AWS.
Airwise combines air-quality forecasts, school activity scheduling, and AI-generated explanations in a dashboard designed for school administrators and teachers. The goal isn't to replace human judgment with an algorithm. It's to make the information behind a scheduling decision easier to understand and act on.
This is the story of how I approached the problem, iterated on the user experience, connected the backend services, integrated AI, and deployed the application.
1. Starting with the problem
I wanted to build something where environmental data could influence a real-world decision.
Schools have recurring outdoor activities, fixed timetables, shared resources, and students who may be exposed to poor air quality during those activities. A forecast alone doesn't tell an administrator which activities need attention or whether another time slot might be preferable.
Airwise approaches this in three stages:
- Understand the forecast: Display air-quality information and estimated PM2.5 levels.
- Evaluate the timetable: Match forecast timestamps to outdoor activities and estimate the average PM2.5 concentration during each activity window.
- Support the decision: Flag activities for review, propose feasible alternative time slots, and generate an AI explanation of the available information.
Airwise is a decision-support tool, not an automated authority on whether an activity is medically or legally safe.
2. Designing the user experience
Getting the backend working was only half the challenge. Airwise also needed an interface that a school administrator could understand at a glance.
Air-quality data can quickly become overwhelming when presented as raw numbers, charts, and forecast timestamps. I wanted the dashboard to answer practical questions rather than force users to interpret every measurement themselves.
That meant spending significant time iterating on the UI/UX: refining the dashboard layout, improving visual hierarchy, making PM2.5 readings easier to interpret, and connecting forecast information to the activities administrators actually schedule.
Designing around decisions, not just data
Rather than treating the dashboard as a collection of charts, I focused on how the information would be used.
The interface brings together the day's air-quality overview, forecast visualisations, outdoor activity schedules, and recommendations. The intention is to help users move from understanding the forecast to identifying activities that might need attention.
The activity schedule was particularly important. A forecast is more useful when it can be interpreted alongside the time and duration of a real activity. The interface therefore connects the air-quality overview to the scheduling workflow instead of presenting them as unrelated features.
Iteration was part of the engineering
The interface went through multiple rounds of changes as the functionality came together. I refined component layouts, styling, information presentation, and how the forecast and scheduling features fit together.
These changes weren't merely cosmetic. In a decision-support application, visual hierarchy and clear explanations affect whether users can understand the information being presented to them.
The process reinforced an important lesson: a technically functional application isn't automatically a usable one. The frontend needs the same deliberate engineering attention as the backend. Components need to work together, information needs to be understandable, and the interface needs to support the user's actual workflow.
3. The AWS architecture
I built the application with Next.js, React, TypeScript, and Tailwind CSS, and deployed it using AWS Amplify Hosting.
For the backend, I used AWS Lambda, Amazon API Gateway, Amazon DynamoDB, and Amazon EventBridge. Each service has a specific responsibility.
Scheduled forecast ingestion
The first pipeline retrieves air-quality forecast data from the Open-Meteo Air Quality API.
The flow is:
Amazon EventBridge → AWS Lambda → Amazon DynamoDB
EventBridge triggers the ingestion Lambda on a schedule. The Lambda fetches forecast data from Open-Meteo, processes the relevant information, and stores it in DynamoDB.
This separates periodic data collection from the web application's request-handling path. Dashboard requests can retrieve stored forecast data without initiating a fresh ingestion operation every time.
Serving forecast data
The frontend accesses the backend through an HTTP API exposed by Amazon API Gateway.
The request path is:
Next.js frontend → Amazon API Gateway → AWS Lambda → Amazon DynamoDB
The API Lambda handles the request, retrieves the relevant forecast data, and returns a JSON response through API Gateway.
This keeps database access in the backend instead of exposing it directly to the browser.
Why serverless?
As a solo developer working under a hackathon deadline, I wanted to avoid spending time managing servers and coordinating a large collection of services.
Lambda let me implement backend functions without managing server instances. API Gateway provided an HTTP interface, DynamoDB handled forecast storage, EventBridge scheduled ingestion, and Amplify hosted the frontend.
The architecture gave me a way to focus on application logic and integration rather than server administration.
4. Turning forecasts into scheduling decisions
Getting data into a database is only one part of the problem. The application also needs to interpret that data in the context of a school timetable.
Airwise's activity-analysis workflow runs in the frontend application.
First, it loads forecast data through the backend API and matches forecast timestamps to scheduled outdoor activities. It estimates the average PM2.5 concentration across each activity's time window.
The application compares that estimate with an illustrative planning reference of 35 µg/m³. Activities above the reference are flagged for review.
The scheduling logic searches for alternative time windows that preserve the activity's duration. Candidate windows are checked for conflicts involving shared resources, teachers, and year groups. Conflicting candidates are rejected, while feasible alternatives can be presented to the administrator.
This creates a more useful workflow than simply displaying a warning: the administrator can see why an activity was flagged and whether a different time window might have a lower forecast estimate.
The 35 µg/m³ value is an illustrative planning reference, not a universal health or legal safety threshold. Forecast-derived activity-window averages are estimates, and a lower estimate does not guarantee that a proposed activity is safe. The administrator remains responsible for the final decision.
5. Adding AI explanations with Amazon Bedrock
I also wanted Airwise to explain the available information in concise, understandable language.
For this, I integrated Amazon Bedrock Mantle with Google Gemma 3 12B IT.
When a user requests an explanation, the frontend sends the activity details to a Next.js API route:
/api/bedrock-explanation The route validates the supplied activity and forecast fields, constructs a constrained prompt, and sends a request to the Bedrock Mantle chat-completions endpoint. The generated explanation is returned to the frontend and displayed in the dashboard.
The model receives information such as the activity's scheduled time, estimated average PM2.5, the illustrative planning reference, and any feasible alternative supplied by the application.
The prompt instructs the model to use only the supplied facts, avoid inventing measurements, and refrain from making new scheduling decisions or claiming that an alternative is guaranteed safe.
This separation is intentional: the scheduling logic checks feasibility, while the model explains the information it receives.
Keeping credentials server-side
The integration also required careful credential handling.
I stored the Bedrock bearer token as an encrypted
SecureString in AWS Systems Manager Parameter Store. The server-side Next.js API route retrieves the parameter at runtime using the Amplify SSR compute role, which has permission to read that specific parameter.The token stays server-side and is not intended to be exposed to the browser.
The AI explanation path is separate from the forecast API's API Gateway and Lambda pipeline. It is initiated by a user request through the deployed Next.js application rather than being part of scheduled forecast ingestion.
6. What challenged me
The architecture diagram makes the system look straightforward. Getting all of it working was less straightforward.
The biggest challenge was integration. A frontend can work locally while the deployed application behaves differently because server-side credentials, IAM permissions, build configuration, and runtime execution all need to line up.
I worked through several parts of the stack:
- AWS permissions: Ensuring services had the access they needed without granting unnecessary privileges.
- Data flow: Connecting the ingestion Lambda, DynamoDB, API Lambda, and API Gateway so the application could retrieve forecast data.
- Deployment configuration: Getting the Next.js application to build and deploy successfully through Amplify.
- AI credentials: Configuring the Bedrock token so the server-side route could retrieve it securely in the deployed environment.
- UI/UX refinement: Iterating on the dashboard layout and information presentation as the forecast, scheduling, and explanation features came together.
- End-to-end testing: Verifying that the AI explanation worked on the live application, not just locally.
The last point was particularly important. A successful build proves that code compiles; it doesn't prove that the deployed application can retrieve credentials, reach the model endpoint, and return a usable response.
Testing the deployed workflow confirmed that the AI integration was working end to end. That was when Airwise became more than a locally running prototype.
7. What I learned
This project changed how I think about both cloud architecture and product development.
First, the value of a cloud service isn't in how many features it offers. It's in whether it solves a specific problem in the system.
- EventBridge handles scheduled triggers.
- Lambda runs ingestion and API logic.
- DynamoDB stores forecast data.
- API Gateway exposes the backend through HTTP.
- Amplify hosts the web application.
- Systems Manager Parameter Store stores the encrypted model credential.
- Amazon Bedrock provides the model inference used for activity explanations.
Second, deployment needs to be part of development from the beginning. A feature isn't finished just because it works on a developer's machine. It needs to work with the permissions, environment configuration, data flow, and runtime of the deployed application.
Third, UI/UX is engineering too. An interface that displays information without helping users interpret it doesn't fully solve the problem. Iterating on the dashboard was essential to bringing the data and decision-making workflow together.
Finally, AI works best when it has a clearly defined role. A model can make information easier to understand, but it should not replace validated scheduling logic or responsible human decision-making.
8. What's next?
Airwise is a working hackathon project, but there is room to improve it.
Some areas I would explore next include stronger monitoring and alerting for the ingestion pipeline, additional API protection and usage controls, more robust handling of upstream data failures, and validation against real school timetables and operational requirements.
I would also evaluate the quality and consistency of the AI explanations across a broader set of activities and forecast conditions.
Most importantly, the application would need careful validation before being relied upon for real school safety decisions. A successful prototype is a starting point, not proof of real-world effectiveness.
Final thoughts
Building Airwise during Environmental Hacks was an exercise in connecting several pieces of technology into a working application.
The project began with a simple question: how can air-quality information help a school decide when to hold an outdoor activity?
Answering it required more than a dashboard. It required a carefully iterated user interface, a forecast-data pipeline, persistent storage, an API, scheduling logic, an AI explanation workflow, and a deployed application that connected them.
AWS provided the building blocks, but the work was in defining their responsibilities, integrating them, debugging the connections, refining the experience, and verifying the result in production.
Airwise is my attempt to turn an environmental forecast into information that people can actually use when making decisions.
Try Airwise
- Live application: https://main.divfs8o5h0w7c.amplifyapp.com
- Demo video: https://www.youtube.com/watch?v=89uTqNc77rc
Technology and acknowledgements
Built for Environmental Hacks 2026 by WeMakeDevs in collaboration with AWS.
Technology stack: Next.js, React, TypeScript, Tailwind CSS, Recharts, AWS Amplify Hosting, AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon EventBridge, AWS Systems Manager Parameter Store, Amazon Bedrock Mantle, Google Gemma 3 12B IT, and Open-Meteo Air Quality API.
AI coding tools used: ChatGpt
Thanks to the organisers for creating an opportunity to build and deploy a solution around an environmental problem.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article