Geolocation + manual search
Backend-normalized weather data
Responsive forecast UI
Problem
Weather products can feel cluttered or unreliable when location handling, API calls, and UI presentation are all pushed directly into the browser.
Solution
I built a split frontend/backend experience where the client focuses on speed and usability while the backend normalizes provider data into a cleaner interface.
Key Features
- City search plus geolocation-based forecast lookup
- Backend proxy for cleaner weather responses
- Saved preferences and responsive visual presentation
- Fallback handling for failed geolocation or provider errors
Technical Decisions
- Moved provider-facing logic to the backend so the client does not have to manage raw third-party API complexity.
- Used React Query to balance freshness and responsiveness in forecast-heavy views.
- Treated animation as a support layer, not the product itself, to keep the UX polished without feeling noisy.
Outcome
The result is a consumer-facing weather product that feels noticeably cleaner and more reliable than a typical demo app, while still showing thoughtful engineering choices under the hood.