The Weather Recap

Alongside fixing the backend issues, I also just shipped a new version of The Weather Recap that I’m genuinely comfortable putting in front of people. I originally launched a bare-bones version of this app a while ago, but I never really felt good about it. Over the holidays, I took the time to rebuild it into something clearer, more consistent, and much closer to the original idea.

The latest version adds clearer overview tables, a past-24-hour hourly view of actual conditions, forecast-vs-actual accuracy charts, and exportable tables for anyone who wants to dig deeper. I also added a small, optional monetization layer: ads by default, with a one-time ad removal option and a tip jar. No subscriptions, no locked features — just a way for people who find it useful to support it.

This is still very much a side project, even though I've spent so much time on this (probably at the behest of my real job). If nothing else, it’s been a good reminder that shipping something you’re proud of often takes longer than shipping something that merely works.

Circling back to my last post - I’ve spent a fair amount of time tightening that system and I wanted to close the loop on what actually stuck.

The final fix wasn’t more infrastructure, but more structure. I split the snapshot process into two explicit phases: a daily dispatch step that deterministically collects and deduplicates pinned locations, and a controlled worker phase that processes those locations with bounded concurrency, retries, and progress tracking. Instead of “run everything now and hope,” the job now behaves more like a queue that drains safely under pressure.

The other major fix was being strict about time. “Yesterday” is now computed in each location’s local timezone rather than implicitly in UTC, which eliminated a whole class of subtle partial failures where nothing crashed but data silently disagreed across views.

The system is now intentionally boring. If upstream APIs throttle, the job slows down instead of failing halfway through. If a single batch fails, the rest still completes. I can tune batch size and concurrency without redeploying. Most importantly, I’ve stopped waking up to mismatched dates and silent data drift.

This still isn’t infinite scale, but it’s honest scale. I’m comfortable with a few hundred daily snapshots on the current setup, and I won’t pay for more infrastructure until usage actually demands it. The main lesson for me was that “simple” cron jobs tend to hide complexity until they don’t.

I thought I had plenty of runway… then my daily cron job hit rate limits at ~100 locations. Much sooner than anticipated.

The Weather Recap takes a daily snapshot for each pinned location so users can compare yesterday’s weather against what the forecast said would happen. The original implementation was intentionally simple: a single Vercel cron job that ran once per day, looped through all stored locations, called Open-Meteo, and wrote the results to Redis. I assumed this would be fine for a long time — maybe up to a thousand daily snapshots. In reality, it started failing at around 100 locations.

I realized something was wrong when I opened the app one morning and saw that about half my locations had a snapshot dated “today,” while the other half were still stuck on “yesterday.” Nothing had crashed. There were no errors visible to users. But accuracy calculations, overview tables, and the landing screen no longer agreed with each other. It was a partial failure .

The root cause turned out to be too many concurrent upstream requests causing 429 rate limits, no backpressure or retry logic, and no separation between what needed to be snapshotted and how fast that work should happen. On top of that, timezone edge cases meant “yesterday” wasn’t consistently defined across locations.

Instead of immediately upgrading infrastructure, I refactored the system into two explicit phases. First, a daily dispatch step collects only pinned locations from active users, deduplicates them by rounded lat/lon, and enqueues them into a Redis queue for the day. Then, a worker process drains that queue in small batches with limited concurrency, retries transient failures, and persists progress so one failure doesn’t poison the entire run. “Yesterday” is now computed in the location’s local timezone rather than UTC.

The result is much more boring. If Open-Meteo throttles, the job slows down instead of breaking. If a batch fails, the rest still completes. I can tune batch size and concurrency without redeploying. And I don’t pay for more infrastructure until I actually need it, or so I hope .

I’m not completely out of the woods yet. This morning I woke up to a full snapshot failure, which forced one more round of fixes. I’m cautiously optimistic it’s solved now, but I’ll keep monitoring as daily snapshot volume grows — this may still top out around a few hundred locations. The upside is that accuracy gaps self-heal over time, so missing a couple days isn’t catastrophic.

If anyone else has run into cron + rate-limit + timezone issues like this, I’d love to hear how you handled it.

I didn’t set out to build a weather app. I just wanted to know what the weather actually was yesterday — and how accurate the forecast had been. That turned out to be surprisingly hard to answer. Most weather apps are (understandably) future-focused, but once I started digging, I got curious:

How good are forecasts really? Does “72 hours out” actually mean anything? Are some places consistently better predicted than others? That curiosity snowballed into a small indie iOS app called The Weather Recap.

The app:
• shows recent actual weather
• compares it to past forecasts
• tracks accuracy over time (24h / 72h / 120h lead times)
• assigns a simple accuracy score per location

I’m not a meteorologist, and I’m not a professional app developer. This was mostly an exercise in curiosity, trial-and-error, and trying to make something understandable instead of flashy. It took a long time (too long) to actually get to a point where I even feel comfortable putting this app out into the wild beyond telling my friends and family to download it

I’m sharing this mostly for others who enjoy data-driven projects or who’ve gone down a rabbit hole that turned into “well… I guess I’m building this now.”

If you’re curious, here’s the app:

https://apps.apple.com/app/id6744126559

Happy to answer questions about the build, data choices, or what surprised me along the way.