Most big days are planned with a mix of local knowledge, recent reports, and a little bit of magical thinking. That is not a bad way to bird. It is how birders learn places. But it also means that a route can quietly optimize for the wrong thing: the most famous hotspots, the longest species lists, or the place that feels like it should be good at sunrise.
I wanted something more explicit. The Big Day Optimizer is a small tool that builds a one-day eBird route from checklist detection rates, drive time, and basic stop constraints. Give it an eBird region, a date, and a day window, and it estimates which hotspots are worth visiting and in what order. The source code is also available on GitHub.
The important part is that it does not only count species as present or absent. eBird checklists are noisy observations, and birding is probabilistic. If one hotspot has a 20% chance of a Black-and-white Warbler and another has a 20% chance, neither stop is a guarantee. But together they are meaningfully better than either one alone. The route score now uses the cumulative chance of seeing each species across the trip, roughly 1 - product(1 - p), instead of treating a species as crossed off after the first plausible stop.
The dashboard tries to make that visible. Each stop shows arrival and departure time, the birds that are expected there, birds that are common across the route, and species that make that hotspot special. The full-trip probability list is the sanity check: it shows which birds the route is actually giving you a good shot at, not just which birds appear somewhere in the underlying data.
There are still caveats. Checklist detection rates are not true abundance. Weather, observer effort, access, and migration timing all matter. The tool also cannot replace a birder who knows that one trail floods, one gate opens late, or one field edge is only good before the dog walkers arrive. The point is not to automate birding. It is to make the tradeoffs visible enough that a human can make a better plan.
I am releasing it now because the first version is useful enough to argue with. If the route looks wrong, that is interesting: maybe the data are thin, maybe the drive-time penalty is too weak, or maybe the optimizer found a plan I would not have considered. Either way, it gives the planning conversation a more concrete starting point than a spreadsheet and a hunch.