How I built BuildoutFeed: NYC restaurant pre-opening intelligence from four public datasets.

BuildoutFeed was a signal-fusion engine for NYC restaurant and bar pre-openings. It ran at buildoutfeed.com from spring 2026 to September 2026. This page is the full case study: what I built, what worked, why I killed the customer-facing product, and what the underlying dataset still powers.

What it was

A daily 7am briefing that fused every available NYC public signal into a ranked worklist of new bar and restaurant accounts, delivered to industry vendors who sell into hospitality: liquor reps, insurance brokers, POS reps, contractors, kitchen equipment vendors, hospitality lawyers.

The thesis: the NYC pre-opening pipeline is a public dataset hiding in plain sight. DOB filings, SLA applications, DOH inspections, NYS DOS LLC filings, community board notices. Nobody was fusing them. Vendors were losing weeks of speed-to-lead because they only heard about a new venue after the license was already active and competitors were already inside.

What I built

The whole ingest-to-briefing stack. Solo.

• Data ingest: NYC Open Data (DOB filings, DOB permits, DOH inspections), data.ny.gov (SLA licenses, NYS DOS LLC filings), community board notices. All free, all public.
• Identity resolution: NYC GeoSearch API for address-to-BBL resolution at 96% match rate on real forward-sampled data. BBL-keyed venue records fusing DOH (88% match), DOB NOW filings (88% match), DOB approved permits (84% match). PLUTO explicitly rejected — its BBL format is incompatible with DOH/DOB.
• Signal fusion: seven-stage pipeline (LLC formed, filed, permitted, under construction, community board notice, liquor filed, liquor approved, DOH inspected, open) plus a distress stage for operating venues in legal or operational trouble.
• Confidence scoring: 3+ independent signals or 2 signals plus high-confidence enrichment produced a digest alert. Below that, venues stayed visible in the substrate dashboard but did not trigger a briefing. Precision over recall by design.
• License event classification: separate axis tagging every SLA record as new issuance, renewal, or transfer via serial pattern plus date-math. Validated on 50-record cohort. Solved the customer complaint that competitors were surfacing renewals as if they were new licenses.
• Enrichment waterfall: Outscraper Google Place API on venues past the alert threshold (83% hit rate when SLA DBA present), NYS DOS LLC officer names for corroboration, planned paid enrichment (Apollo, Clearbit) on high-confidence hits.
• Product surface: Next.js app on Vercel. Kanban prospecting view. Distress feed at /distress for hospitality lawyers. Daily digest email via Resend. Full-stack Supabase Postgres with `buildoutfeed` schema, custom enums, views, and identity-resolution helpers.
• 3 recurring crons: nightly ingest (Mac mini scheduled task with plist installer), daily nurture emails, alert scoring.

What it demonstrated

I can build real public-data pipelines. Not a scraper that breaks in three weeks. A daily ingest that resolves cross-source identity at 96% and holds up over months.

I can architect for domain-specific truth. The two-axis model (physical space: new build vs renovation vs unclear × regulatory event: new issuance vs renewal vs transfer vs unknown) came from real customer feedback. When Brittany at Winebow flagged that Georgie's at 161 8th Ave was being missed because it was a renewal not a new issuance, I shipped the license event classifier the next day. That is the loop that makes a data product actually useful.

I can hold high precision on a noisy public dataset. The alert rule (3+ signals or 2 + enrichment) meant 30-50 alerts per month instead of the 200+ noise firehose competitors were shipping. Fewer alerts, higher quality, no filter tax on the sales rep.

I can run enrichment as a bounded cost problem. Outscraper hit rate measured, gated by SLA DBA presence, capped at ~$2/mo at full pipeline volume. The paid enrichment waterfall (Apollo etc.) was designed to only run on 70+ confidence hits, keeping cost at ~$15-100/mo instead of $500+.

Why I killed the customer-facing product

Wrong audience, right data.

The vendors who needed this briefing the most were also the hardest to reach and the slowest to buy. Liquor reps who would benefit did not have a habit of paying for a SaaS. Hospitality lawyers had budget but their sales cycle is slow and their volume is low. Insurance brokers and equipment vendors got the value but were three degrees removed from any warm intro I had.

I could have kept grinding the go-to-market. I chose to pull the plug on the customer-facing product instead. The reason: I was pouring calendar-hours into sales motions for a product that could not compound without a critical mass of vendor subscribers I did not have a fast path to reach.

The kill decision was about audience-market fit, not about the data or the engineering. The data pipeline works. The identity resolution holds up. The classification logic is validated. What did not work was me being the person to sell that pipeline into that vendor set.

What lives on

• The NYC pre-opening dataset continues to feed the BarTeams weekly newly-licensed venues digest at barteams.com/events. The nightly ingest still runs. The Supabase schema is still queried every Friday morning. The public dataset never stopped being useful, and it now serves an audience I actually have distribution to.
• The identity-resolution pattern (GeoSearch → BBL → cross-source join) is now a reusable pattern I apply to any client with a public-data problem.
• The engineering now informs how I scope data-product work for KMS Connect clients: precision over recall, bounded enrichment cost, domain-specific truth models, real feedback loops with real users.

How to bring it back

The pipeline never stopped. The nightly ingest runs, the Supabase schema holds the full NYC pre-opening dataset, the identity resolution keeps compounding. What is dormant is the customer-facing product, not the data. If the right partner shows up, the briefing goes back out in a week.

What that looks like:

• Vendor partnership: a beverage distributor, POS vendor, insurance broker, or hospitality equipment supplier wants exclusive first-look at NYC new-account signals for their sales team. I run the ingest. Your team gets the daily briefing. Estimated deploy time: 5-7 days to configure the vendor-specific alert threshold, contact enrichment waterfall, and delivery format (email, Slack, CRM push).
• Trade association or industry group: a group (bar association, restaurant lobby, hospitality nonprofit) wants a member benefit: the NYC pipeline briefing as a benefit of membership. Same engine, different delivery. Estimated deploy time: 2 weeks to add member-only auth and per-borough filtering.
• White-label the pattern for another city: the identity-resolution architecture is city-agnostic. Chicago, LA, Miami, Austin, London all have the same shape of public data (permits, licenses, health inspections). Estimated deploy time: 4-6 weeks per city to source the equivalent open-data feeds, tune the GeoSearch equivalent, and validate cross-source match rates.
• Custom data product on the pattern: you have a different domain (construction pipeline, retail openings, franchise expansion, healthcare licensing) with the same public-data-is-inert problem. Scoped as a KMS Connect engagement.

If any of these fit: tell me what you are running.

What it means for what I ship next

If you have public data that is technically accessible but operationally inert, and you want it turned into a real product surface with a real audience: tell me what you are running. I build data products that keep running after the launch post.

If you want the raw NYC restaurant pipeline dataset or a custom vendor briefing for your own book, I still build those on a project basis.