Five Extra Minutes: Building AeroRoute with AWS Amplify and Lightsail
AeroRoute helps people compare walking routes, extra travel time, and estimated PM2.5 exposure. This Air-track project combines AWS hosting, a working journey planner, and lessons about turning environmental data into a decision people can understand.
Connaught Place to India Gate. A starting point, a destination, and five extra minutes to spare.
For someone walking through Delhi, those five minutes create a practical question: is there a reason to take a different route?
I built AeroRoute around that decision. The application brings travel time, a personal detour budget, and estimated outdoor PM2.5 exposure into one journey planner. AWS Amplify hosts the frontend, and Amazon Lightsail runs the backend.
For the Air track, the focus is deliberately specific: help people compare walking journeys with air-pollution context, within the time they actually have. The longer-term goal is to support choices that reduce exposure where reliable evidence supports them. The working prototype establishes the comparison workflow; measuring that exposure benefit is the next challenge.
Start with the person making the journey
A useful environmental tool has to fit an ordinary decision.
AeroRoute asks for a starting point, a destination, and the maximum extra time the traveller can spare. Someone with five minutes available should be able to express that directly.
The interface follows three steps: set a journey, compare the options, and start when ready. Planning and comparison work without creating an account. Google sign-in is requested when starting GPS navigation.
Locations can be searched, pinned on the map, or selected using the device’s current location. A recorded Delhi example makes the comparison flow easier to explore.
The app also offers car and motorcycle modes, but the walking comparison is the core demonstration. Motorcycle mode currently uses car-routing estimates and labels that approximation.
Turn five minutes into a rule the app can explain
AeroRoute obtains actual route geometry and travel timings from Mapbox. It identifies the fastest route among the evaluated candidates and applies the user’s allowance:
Eligible route time ≤ fastest evaluated route time + maximum extra time.
For illustration, if the fastest evaluated journey takes 30 minutes, a five-minute allowance admits a 34-minute option but excludes a 38-minute one. These numbers explain the rule; they are not measurements from the screenshots.
Where sufficient data supports the entire path, the app calculates an estimate by adding PM2.5 concentration × time spent on each route segment. Its unit is µg·min/m³.
That calculation captures a useful trade-off: a longer walk can increase total estimated exposure even if the concentration is somewhat lower. A detour has to be evaluated, not assumed to help.
Use AWS to make the complete workflow accessible
The frontend handles the map and interaction. The backend coordinates routes, checks data support, and calculates the comparison.
Component | Its role in AeroRoute |
|---|---|
AWS Amplify Hosting | Hosts the Next.js application built with React, TypeScript, and Tailwind CSS. |
Amazon Lightsail | Runs the FastAPI backend in Docker on Ubuntu, with Caddy handling HTTPS. |
Mapbox | Supplies map rendering, travel paths, and route timings. |
Supabase PostgreSQL | Stores historical pollution observations and snapshots for recorded replay. |
Firebase Authentication and Firestore | Support Google sign-in and private recent-route history. |
AWS Amplify Hosting supports Next.js and a Git-based deployment workflow. That gives the interface a repeatable path from repository changes to a hosted application.
The backend deployment involved a real constraint: creating the managed container service encountered a quota limitation. The project instead deployed Docker on an Ubuntu Amazon Lightsail instance in Mumbai. This kept the API deployable with the available resources, while making server maintenance an explicit responsibility.
The release workflow builds a container for a specific source commit and checks its readiness. If local readiness fails, it can restore the previous container where available. A final HTTPS check verifies the running source version.
These are practical parts of execution: knowing which version is running, keeping private credentials on the backend, and having a recovery path when a release fails.
Learn what “current” actually means
One implementation problem had little to do with the map.
An earlier live-data path loaded the latest stored pollution snapshot. But the newest snapshot could still contain old observations. Fetching it again did not make those observations fresh. Once readings exceeded the two-hour freshness policy, they could no longer support a live estimate.
The lesson was precise: freshness follows the source’s timestamps and validity, not the time the application retrieved it.
The newer implementation requests current regional forecasts from Open-Meteo and Copernicus CAMS along the routes. Historical replay remains a separate mode. Real-provider checks have exercised this update locally; its frontend and backend release verification remains outstanding.
The forecast also has a spatial limit. CAMS Global has approximately 45-kilometre resolution, so nearby Delhi routes can share a forecast cell. In that case, travel time may account for the difference in their estimated exposures. Open-Meteo documents the model resolution .
A detailed street map cannot make regional pollution data more precise. The interface therefore labels data sources and historical replay, and leaves unsupported full-route scores unavailable.
Accept the result, even when the detour does not win
A historical evaluation compared six exploratory journeys using recorded November 2025 observations. In five, the fastest route also had the lowest eligible model estimate. The sixth retained only one candidate after route-quality screening.
That evaluation did not demonstrate a beneficial lower-exposure detour.
For a tool asking people to spend their time differently, this is a useful result to report. The comparison needs to allow for the possibility that the evidence gives no reason to take a longer route.
The map uses colour carefully: green marks the selected path, while grey shows another candidate. Green does not certify cleaner air.
Design for the phone used during the journey
Once a journey begins, the traveller’s location becomes another changing input.
AeroRoute includes GPS-based guidance and rerouting, with controls for recentering, map direction, route overview, and stopping the journey. The mobile screenshot captures a rerouting request in progress, including a displayed GPS accuracy estimate of ±12 metres.
Making that state visible helps the traveller understand what the application is doing while a route update is being requested.
Measure the impact that matters next
Today, the prototype brings route alternatives, time allowances, and supported pollution estimates into a single comparison. A traveller can inspect the trade-off and see when the data cannot support a conclusion.
Establishing an exposure benefit requires more evidence. The scores estimate outdoor ambient exposure; they do not measure inhaled dose or model car-cabin filtration. Historical estimation errors also varied between evaluation periods, so percentage-reduction claims remain withheld.
The next milestones are deployment verification for the forecast update, broader real-device testing, and measurements along actual journeys. Those measurements should test whether a proposed detour reduces exposure and whether that reduction justifies its extra time.
Building AeroRoute has made one principle especially clear to me: environmental information becomes useful when people can understand both the choice and the evidence behind it.
Five extra minutes belong to the traveller. AeroRoute is being built to help them decide how to spend them.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article