From Idea to Integration: Building an End-to-End Environmental System During AWS Environmental Hacks
A behind-the-scenes look at how Team .env brought hardware, embedded systems, AWS cloud services, and a web application together under hackathon time constraints. Explore the engineering decisions, integration challenges, and rapid iterations that turned an ambitious idea into a working prototype.
What happens when you have an ambitious environmental idea, a limited amount of time, physical hardware to build, cloud services to integrate, and a web application to bring everything together?
You stop thinking about individual components and start thinking about how to make an entire system work.
That was the challenge we took on as Team .env during AWS Environmental Hacks 2026.
Our goal was to explore an algae based bio air purification system supported by embedded sensing, wireless communication, AWS cloud infrastructure, and a web application. We did not want to build just another dashboard that displays sensor values. We wanted to connect a physical system to a digital platform that could help us monitor, understand, and eventually evaluate its environmental performance.
Over a short development window, we had to make decisions about hardware, firmware, communication, cloud architecture, and the user experience. Every layer had to fit into the same system.
Here is how we approached that challenge.
1. We Started With a Real World Problem
The first question was not which microcontroller to use or which AWS service to choose.
It was what would make this project genuinely useful.
Environmental monitoring is important, but collecting readings is only one part of the problem. We wanted to explore whether monitoring could be connected to a physical treatment system, allowing us to study environmental conditions and evaluate how the system behaves over time.
That led us to an algae based purification concept.
The physical design brings together an air intake, a blower, a fine mesh, a water circulation mechanism, and an algae containing chamber with an inclined surface. A pump moves water through a hose and distributes it across the surface, creating an arrangement intended to improve interaction between air and the algae containing medium.
The idea was exciting, but it also introduced a challenge. We were no longer building only a software application. We were working across biological processes, mechanical components, embedded electronics, networking, and cloud infrastructure.
The key was to break the problem into smaller parts that we could develop and integrate incrementally.
2. Turning the Concept Into Hardware
One of our biggest engineering challenges was translating the concept into a physical arrangement.
Every component had to serve a purpose. The blower establishes the air intake. The water pump circulates water through the hose. The inclined surface provides an area for water to flow and interact with air. The enclosure brings these components together while accommodating the electronics and communication hardware.
The algae chamber is central to the concept because algae can take up carbon dioxide through photosynthesis under suitable conditions. However, actual carbon uptake and oxygen production depend on the biological setup and operating conditions, so these outcomes must be measured rather than assumed.
Thinking through the physical layout helped us understand an important lesson early on.
A product is not a collection of components. It is a system of components that must work together.
That principle guided our approach to the electronics and software as well.
3. Giving the Hardware a Voice
For our current monitoring prototype, we selected the ESP32 WROOM 32, a BME680 environmental sensor, and an SX1278 LoRa radio.
The ESP32 acts as the controller. The BME680 provides temperature, humidity, atmospheric pressure, and gas resistance readings. The LoRa module enables wireless communication with compatible nearby receivers.
We developed the firmware to collect the readings, format them as JSON, and transmit telemetry approximately every ten seconds.
But we wanted the data to travel beyond the device itself.
We established two independent communication paths.
The first uses LoRa to transmit telemetry to a compatible receiver. This gives us a foundation for communication between nearby units without requiring every unit to connect directly to the internet.
The second uses WiFi and HTTPS to send telemetry to our AWS backend.
This approach allowed us to work on cloud connectivity while retaining the ability to experiment with local wireless communication.
The current implementation sends data through both paths independently. Automatic rerouting through another unit during an internet outage remains a future improvement.
4. Connecting the Physical World to AWS
This was one of the most important parts of our engineering journey.
We needed a reliable way to receive readings from the ESP32, process incoming requests, and store the data for future use.
Instead of maintaining a dedicated backend server, we chose a serverless architecture using AWS services.
Our current pipeline is:
ESP32 → Amazon API Gateway → AWS Lambda → Amazon DynamoDB
Each service has a clear responsibility.
Amazon API Gateway
API Gateway provides the HTTPS endpoint through which the ESP32 submits telemetry. It creates a managed entry point between the embedded hardware and our cloud application.
AWS Lambda
Lambda processes the incoming request and validates the device token before the reading is stored. This keeps the ingestion logic in the cloud and separates it from the firmware.
Amazon DynamoDB
DynamoDB stores the incoming readings, giving us a persistent data source that can support future retrieval, historical analysis, and dashboard visualizations.
What made this architecture useful was the separation of responsibilities. We could work on the embedded firmware, request processing, and data storage as distinct components while keeping a clear path between them.
It also gave us a foundation that can evolve as more units are introduced.
5. We Did Not Want the Data to Stop at the Database
Collecting data is useful. Making that data understandable is what allows people to work with it.
That is where our web application comes in.
We are developing the digital side of the project around the idea of a centralized interface for monitoring environmental units and exploring their readings.
The direction includes a network overview, individual unit details, historical charts, communication status, and a visual representation of deployed devices.
As the hardware evolves, the same interface can incorporate suitable inlet and outlet measurements, airflow, water conditions, and other operational parameters.
The most important architectural decision is to connect the application to actual stored telemetry.
The ESP32 sends readings into AWS. A separate, secure read API can then provide the frontend with the latest readings and historical records. This keeps device credentials out of the browser and separates data ingestion from data retrieval.
The result is a clear relationship between the physical system, the cloud backend, and the user interface.
6. The Real Challenge Was Integration
In a short engineering sprint, individual components can appear to work perfectly while the complete system still fails.
A sensor can produce readings. Firmware can compile. An API can return a response. A database can accept records. A frontend can render a page.
But the real test is whether a reading generated by the hardware travels through the entire pipeline and becomes usable information in the application.
We approached this by breaking integration into manageable checkpoints.
First, verify the sensor readings. Then check the firmware payload. Test the communication path. Confirm that the API receives the request. Inspect the database record. Finally, connect the stored data to the application.
This makes failures easier to isolate and reduces the temptation to debug every layer simultaneously.
The same thinking applies to physical engineering. A running pump does not prove that water circulates correctly. A spinning blower does not establish the actual airflow. A functioning algae chamber does not prove carbon capture.
Each part needs to be tested according to its intended function.
Under time pressure, we learned to prioritize a working foundation over an impressive list of unfinished features.
7. The Engineering Decisions That Shaped Our Approach
Three decisions were especially important.
Build the data pipeline before adding complexity
We prioritized getting telemetry from the embedded device into persistent cloud storage. This established a foundation for the web application and future analytics.
Keep communication and processing responsibilities separate
LoRa supports local wireless communication, HTTPS provides direct cloud connectivity, Lambda handles request processing, and DynamoDB stores the readings. Each layer can evolve without requiring us to redesign everything at once.
Make room for future improvements without pretending they already exist
Our current BME680 measurements provide useful environmental context, but they do not directly measure CO₂ or PM2.5. Evaluating purification performance will require appropriate sensors, airflow measurements, and repeatable experiments.
Being precise about these boundaries helps us decide what to build next and prevents us from confusing a working prototype with a fully validated environmental solution.
8. What AWS Made Possible
For us, AWS was not simply a place to host an application. It provided the connection between the physical hardware and the digital system.
API Gateway gave the ESP32 a managed HTTPS endpoint. Lambda provided request processing without requiring us to operate a dedicated server. DynamoDB provided persistent telemetry storage.
Together, these services established the cloud foundation for the project.
The next step is to expose the stored data through authenticated read endpoints, connect the web application to those endpoints, and make historical records available for visualization and analysis.
As the network grows, we can investigate a dedicated LoRa gateway, more resilient message delivery, and additional processing for larger volumes of telemetry.
The value is not in using as many cloud services as possible. It is in selecting services that solve real problems within the system.
9. What Comes Next
The current implementation is the beginning of a larger engineering effort.
We want to continue refining the physical treatment unit, introduce the measurements needed to evaluate its performance, and complete the dashboard integration.
We also plan to explore a distributed communication architecture in which field units transmit through LoRa to an internet connected gateway.
With reliable measurements and enough historical data, we can investigate environmental trend analysis, anomaly detection, pollution forecasting, and predictive maintenance.
Each of these capabilities depends on data quality and proper validation. Our priority is to build the foundation first, then add intelligence where it provides measurable value.
Final Thoughts
Looking back at this development sprint, the most meaningful part was not a single sensor, a cloud service, or a user interface.
It was the process of connecting them.
We started with an environmental idea, translated it into a physical concept, developed an embedded monitoring path, connected the hardware to AWS, and established the foundation for a web application that can make the resulting data useful.
There is still work ahead, particularly in validating the physical treatment process and measuring its real environmental impact. But we now have a clearer engineering foundation on which to continue building.
For Team .env, AWS Environmental Hacks has been an opportunity to think beyond isolated features and work toward an integrated system.
The real achievement is not just getting individual components to work. It is making them work together toward a meaningful problem.
Team .env
Srevarshan S, Pranav S, Shanmyukthaa D, and Archana S
AWS Environmental Hacks 2026
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article