ChurchMap
What is the minimum a first-time visitor needs to know, and how does missing data break that task?
Public place data with lazy enrichment. Coverage and freshness vary by city, which is the interesting part of the problem.
- Problem
- A directory with thousands of rows can still fail a first-time visitor if the four fields that visit depends on are the missing ones.
- My contribution
- I built the product end to end — geolocation search over Postgres and pgvector, lazy profile enrichment, and freshness and coverage tracking on the crawl itself.
- Current result
- A live site, and a reframing: coverage is measured against a required field set for one user situation rather than by row count.
The task
What is the actual product problem?
The build is a geolocation-first map with enriched profiles: Supabase Postgres with pgvector, lazy enrichment so a profile is filled in when it is first needed rather than crawled up front, and freshness and coverage tracking on the crawl itself.
The framing that took longest to reach: "we need more data" is not a project. A first-time visitor needs a small set of fields — service times, location, whether it is currently active, and how to get there. A directory with ten fields and the wrong four missing fails the task as completely as an empty one.
What the data looks like
What actually breaks?
Coverage is strongly uneven by city, and the long tail is missing exactly the fields the task depends on. Enrichment fills profiles on demand, which keeps cost sane, but it makes coverage a function of traffic rather than of importance.
The failure that generalizes past this project: a pipeline reporting no errors is not a healthy pipeline. Silent staleness and partial coverage produce clean logs and a broken product.
How coverage should be measured
How would coverage be tied to task success?
- Pick one city and one user situation — new to the area, looking for a service this weekend.
- Define the minimum field set that situation requires, before looking at what the data happens to contain.
- Measure coverage of that field set, not row count. A hundred thousand rows missing service times is zero coverage for this task.
- Then measure task success: can a person actually pick a place and turn up.
Next
What happens next?
- Narrow to one city and one user situation, and seed the minimum fields by hand where the crawl cannot reach.
- Report freshness and coverage against that field set as the product health metric.
- Expand only after the narrow case actually completes the task.
Limitations
What this case does not establish.
- Coverage is uneven across cities, and search quality follows coverage.
- There is no evidence of product-market fit here, and I do not claim any.
- Enrichment freshness is monitored, not guaranteed. A crawl that logs no errors can still be quietly stale.
- Observational
- Measured on data that was not randomized. Supports hypotheses, not causal claims.