AC Finder
A community map for finding air-conditioned venues during heatwaves. Built in days.
2026-06-01
Graz hit 38°C last summer. I wanted a map of places I could actually sit and work. Nothing existed. I built one.
The three-pane layout: a distance-sorted list on the left, a detail panel with the one contribution question in the middle, and the map carrying everything. Filter chips across the top narrow by venue type and by what you actually need, WiFi, work-friendly, no purchase required.
The constraint that shaped everything
Google Places API is expensive at runtime. If you load 50 venues on a map, that is 50 API calls per user visit. I did not want to pay per visit, so I moved all the data work to a one-time pipeline.
The pipeline mines OpenStreetMap and Google Places reviews for AC signals: a brand whitelist (chains that reliably have AC) and keyword mining on reviews ("freezing", "air con", "too cold"). It runs once, outputs a static dataset, and the map serves that. Runtime cost: near zero.
What it actually is
Next.js on Vercel. Supabase with PostGIS for the venue data and geospatial queries. Mapbox for the map. Community voting -- three votes in either direction and the majority wins. localStorage dedup so the same person cannot vote twice.
The voting UI is deliberately the smallest thing that could work. Anyone asking "does this place have AC?" is standing outside in 38°C heat holding a phone, so the interaction is one question and two buttons. No account, no form, no rating scale. An honest "unverified" label is better than a fake confidence score, so unverified is what it says until real votes arrive.
I directed the architecture and built it with Claude Code. It took a few days.
The real product
The data pipeline is the actual innovation. The map is the interface. Most "apps" are the interface. The interesting problem was getting reliable, cheap AC signal at scale -- not building a map.