Big days are funny because they are supposed to feel like fieldcraft, but a lot of the result is decided at the kitchen table the night before. I usually end up with too many eBird tabs open, a rough sense that one marsh should be good early, and a bunch of little guesses that are hard to compare. Is it worth driving twenty minutes for a place that sometimes has a Black-and-white Warbler? What if two other stops each have a weaker chance? How much am I just picking the hotspots I already like?
I made the Big Day Optimizer to make those tradeoffs more explicit. Give it an eBird region, a date, and a day window, and it builds a one-day route from checklist detection rates, drive time, and stop constraints. The source code is on GitHub, mostly because I want the assumptions to be visible rather than hidden inside a spreadsheet.
The main thing I wanted to fix was the way route planning can quietly become a checklist-length contest. A bird should not be treated as crossed off just because one hotspot has a record for it in early May. A 20% bird is still missed four out of five times. But two or three 20% chances are meaningfully different from one, and that difference is exactly the sort of thing I find hard to reason about when I am also thinking about sunrise, traffic, bathrooms, and whether I have packed enough snacks.
So the optimizer scores a route by stacking probabilities across the whole day. In rough terms, it uses 1 - product(1 - p) to estimate the chance of seeing each species somewhere on the trip. The dashboard shows that at two levels: each stop has its expected birds and local specialties, and the full-trip list shows which species the route is actually giving you a decent shot at.
This is still not a birding oracle. eBird checklist rates are not abundance. They mix observer effort, access, weather, migration timing, and all the weird little local facts that do not fit cleanly into an API. A person who knows that one trail floods, one gate opens late, or one field edge is only good before the dog walkers arrive is bringing information the model does not have. The point is not to replace that knowledge. The point is to put a clearer first draft on the table.
I am releasing it because the first version is useful enough to argue with. If the route looks wrong, that is useful too. Maybe the data are thin. Maybe the drive penalty is too weak. Maybe the optimizer found a plan I would not have considered. Either way, it gives the planning conversation a better starting point than a pile of tabs and a hunch.