The minyan finder problem: the data nobody kept fresh

The minyan-finding problem is deceptively old-fashioned. It is not a computation problem — there is no algorithmic difficulty in listing shuls near a highway exit. It is a data freshness problem: minyan times change with the zman, the season, the summer schedule, the building move nobody updated. Every directory ever printed was partly wrong by the time it was bound, and every crowd-sourced list decayed the moment its founding enthusiast got busy. Travelers learned to trust the phone call and distrust the listing — rational behavior toward a dataset with no maintainer.

Why the data kept dying

Three structural reasons, worth naming because the fix must answer each:

• No owner. A volunteer list has no one whose job is Tuesday's update. Institutional data survives only when an institution carries it.
• No feedback loop. Print a wrong minyan time and nothing tells the printer. Systems without correction channels drift monotonically wrong.
• No integration. Even accurate lists lived apart from the map — a PDF here, a website there. The traveler at the exit ramp needed navigable answers ("route me to the 6:50"), and a listing that cannot route is homework, not help.

The mainstream mapping giants never solved this — not from incapacity but indifference; the dataset is too small for their economics and too alive for their update cycles. The category error was waiting for them.

The layer answer

What changes the problem is treating shul data as infrastructure inside a navigation product built for this community — the position KolBo Go occupies as, in the homepage's words, "the first kosher navigation ever made." The pieces the layer model supplies, in exactly the shape the data problem demands:

1. An owner. The platform carries the dataset as a product surface, not a side project — the mapping ambition described in every shul on the map. Maintenance becomes someone's Tuesday.
2. A loop. Users at the destination are the correction channel — the confirmed arrival, the flagged change — feeding a dataset that heals instead of decays.
3. Navigation-native answers. The query is never really "list shuls"; it is "get me to Mincha in time." Fusing the shul layer with routing and with zmanim awareness turns a directory row into a decision: the 6:50 is nine minutes away; the 7:10 is safer.

“A directory tells you where shuls were. Infrastructure tells you where Mincha is.”

kolbo.life

The traveler's craft, meanwhile

Tools or no tools, the road has a craft tradition worth keeping:

• The concentric search. Nearest first, but know the corridor: in unfamiliar territory, the reliable minyan is often in the bigger community twenty minutes on, not the sporadic one nearby — a judgment the road-trip planning discipline bakes in before departure.
• The phone-call verification. For anything schedule-critical (the last Mincha of the afternoon), thirty seconds with the shul office converts probability into certainty. A business traveler's version of this — stacking the call into the drive — is part of the calls-on-the-road playbook.
• The buffer zman. Plan to arrive for the minyan before the one you need. The traveler who aims at the early option and misses still davens b'tzibbur; the one who aims at the last option and misses davens at a rest stop.
• The reciprocity habit. When the data helped you, close the loop — confirm, correct, thank the gabbai. Travelers are the dataset's immune system.

The three questions to settle before any trip

A one-paragraph pre-trip ritual keeps the road calm: know your first minyan option after departure, your last reliable one before arrival, and the single phone number you would call if both fall through — usually the destination community's shul office. Written on the plan page, those three answers convert the entire tefillah layer from an anxiety into an itinerary line, and they take less time to find than one wrong exit costs.

Frequently asked questions