HeatShift: Building a Heat-Aware Workforce Planning Platform on AWS
Explore how HeatShift combines weather data, heat-risk assessment, workforce scheduling, and safety intervention optimization using a serverless AWS architecture. Learn about the technology stack, cloud deployment, and lessons from building the project.
Innovation-driven Technologist
Introduction
Extreme heat creates challenges for outdoor workers, campus operations, facility managers, and municipal teams. Planning work without considering changing weather conditions can increase heat exposure and make resource allocation more difficult.
HeatShift is a heat-aware decision-support platform designed to help organizations assess environmental conditions, generate work plans, estimate hydration requirements, and optimize safety interventions within a budget.
The goal is to bring weather information and operational planning tools into one application while exploring how serverless cloud architecture can support a practical, data-driven solution.
What Is HeatShift?
HeatShift connects weather information with tools for heat-risk assessment and workforce planning.
Its main capabilities include:
- Weather integration: Retrieves weather information and forecasts from Open-Meteo.
- Heat-risk assessment: Evaluates heat-related environmental conditions to support planning decisions.
- Workforce planning: Generates work plans intended to account for heat conditions.
- Hydration estimation: Estimates water requirements based on the configured outdoor team size.
- Intervention optimization: Helps evaluate how a safety budget can be allocated across potential interventions.
- Impact tracking: Provides an interface for tracking intervention-related information during a session.
Together, these features aim to help users consider environmental conditions alongside operational constraints.
HeatShift is a decision-support application, not a medical diagnostic tool or a replacement for official heat-safety guidance.
Technology Stack
The project combines a modern web frontend with a TypeScript backend and serverless AWS infrastructure.
Frontend
The frontend uses:
- Next.js
- React
- TypeScript
- Tailwind CSS
These technologies provide the application interface for viewing heat-risk information, exploring work plans, and reviewing intervention options.
Backend
The backend uses Node.js and TypeScript, with Zod for request validation. The application exposes API endpoints for key operations, including heat-risk evaluation, work-plan generation, intervention optimization, and weather information.
Separating these operations into backend functions helps organize application logic and provides a clear interface between the frontend and backend.
Weather Data
HeatShift integrates Open-Meteo to obtain weather information. This data supports the application's environmental assessment and planning workflows.
Weather-based estimates should be interpreted with appropriate caution. Their usefulness depends on input quality, the calculation method, and the conditions represented by the available data.
AWS Architecture
AWS provides the hosting, API access, serverless compute, deployment, and alerting components used by HeatShift.
AWS Amplify
AWS Amplify hosts the Next.js frontend, making the web application accessible through a deployed URL.
Amazon API Gateway
Amazon API Gateway exposes HTTP endpoints that allow the frontend to communicate with the backend.
AWS Lambda
AWS Lambda executes the backend application logic. The serverless approach allows the main operations to run as separate functions without requiring a continuously managed application server.
AWS Serverless Application Model (SAM)
AWS SAM is used to define, build, and deploy the backend serverless stack. It supports a repeatable infrastructure deployment workflow.
Amazon CloudWatch and Amazon SNS
Amazon CloudWatch supports monitoring and billing alarms, while Amazon SNS can deliver alarm notifications through email subscriptions.
These services provide a foundation for observing the deployment and receiving billing-related notifications. Billing alerts are not guaranteed spending caps and do not automatically shut down all resources.
The frontend is hosted in the AWS Mumbai Region, while the backend is deployed in the AWS Hyderabad Region.
How the Application Works
At a high level, the workflow is:
- A user opens the HeatShift frontend.
- The frontend sends requests to backend endpoints through API Gateway.
- Lambda functions process the requested operation.
- Weather information from Open-Meteo supports relevant environmental assessments.
- The backend returns results for the frontend to display.
- Users can review heat-risk estimates, work plans, hydration requirements, and intervention options.
This architecture separates the user interface from backend processing and provides a clear path for extending the application.
Engineering Challenges and Lessons
Building HeatShift involved more than creating dashboard screens. The project also required connecting external weather data, validating API inputs, organizing backend operations, and deploying infrastructure in AWS.
Several engineering principles shaped the implementation:
Input validation matters. Backend requests should be checked before application logic uses them. Zod helps define and validate expected input structures.
Failures should be visible. When an API request fails, the interface should communicate the issue instead of silently presenting fallback calculations as live results.
Deployment is part of the application. A working local environment is only one part of the process. Hosting the frontend, exposing API endpoints, deploying Lambda functions, and configuring monitoring are all important parts of delivering a usable cloud application.
Transparency builds trust. Users should be able to distinguish live API results from demonstration data, estimates, and locally generated fallback results.
Limitations and Responsible Use
HeatShift is an evolving project, and its current capabilities should be understood in context.
Some baseline schedules and scenarios use demonstration data. The Impact Tracker is session-based rather than a persistent record of verified real-world outcomes. Projected benefits should therefore be treated as illustrative, not as measured evidence of improved safety or cost savings.
Heat-risk estimates are intended to support planning and should not be represented as certified measurements or medical assessments unless separately validated. Organizations should continue following applicable workplace safety requirements and official heat guidance.
These distinctions are important when developing applications that may influence decisions about worker safety.
What Comes Next?
Potential future improvements include persistent storage for work plans and impact records, stronger evaluation of heat-risk calculations, expanded automated testing, and additional operational monitoring.
Further development could also explore how to evaluate proposed schedules against practical constraints while preserving clear explanations of recommendations and their limitations.
Conclusion
HeatShift demonstrates how a modern web application can combine weather data, heat-aware planning, resource optimization, and serverless cloud services in one project.
By using Next.js, TypeScript, Open-Meteo, AWS Amplify, API Gateway, Lambda, SAM, CloudWatch, and SNS, the project brings together full-stack development and cloud engineering around a practical environmental challenge.
The central lesson is that useful software requires more than functionality: it also requires careful validation, reliable failure handling, responsible communication, and transparency about what the system can—and cannot—prove.
HeatShift is a step toward exploring how cloud technology can support more informed decisions in a warming world.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article