Inspiration

Most independent restaurants pick a location on gut feel and a broker's pitch. Chains have site-selection teams; first-time owners don't. Chicago publishes years of license, inspection, population, employment and transit data, but almost no restaurateur can turn it into an answer to three questions: Where should I open? What can I afford? How risky is it?

What it does

OpeningTable is a site advisor for independent restaurants in Chicago. Enter a budget and a restaurant type, pick a ZIP, and every block on the map (an H3 cell) shows store size, startup cost, monthly P&L, payback period and risk, each with its data source. Every site report opens with a plain-English summary, a Chicago checklist for licenses, permits and the lease, and questions to ask before signing.

How we built it

  • Data pipeline (Python): downloads Chicago business licenses, food inspections, population, LODES employment, CTA ridership and an Overture restaurant snapshot, then cleans them and aligns them in time.
  • Three models: a cuisine classifier, a license survival model (1,000-day survival for a new independent restaurant) and a supply gap model.
  • Financial model: runs in the browser as a Monte Carlo simulation over 41 parameters. Each parameter has a triangular distribution, a cited source, and a status: sourced, partially sourced, or no public source.
  • Frontend and backend: React + Vite + deck.gl for the map, FastAPI for the server.
  • Plain-English report: DeepSeek writes the report but never produces the numbers. The server checks every number in the draft against the model output, and anything that can't be matched is sent back for one revision.
  • Self-iteration: retraining runs automatically every week. A new model is promoted only if it scores no worse than the current one; otherwise it rolls back.

Challenges

  • Honest numbers hurt. When we replaced placeholder assumptions with sourced figures, P50 payback for one Italian restaurant in 60614 went from 27 months to more than 72. We kept the honest number.
  • Missing data. Seven parameters have no public source, and rent is researched for only 7 neighborhoods. Instead of hiding these gaps, we flag them in the app.
  • Live web data didn't hold up. 280 web searches produced only 5 verifiable rents, and coverage skewed toward popular neighborhoods, so we removed the feature.
  • LLMs invent numbers. We had to build a tracer that matches every number in the text back to the model output, even after rounding.

What we learned

  • A model is only as useful as how honest it is about what it doesn't know.
  • An LLM works best explaining numbers, not creating them.
  • Making a city's public data usable takes most of the work: cleaning it, lining it up in time, and showing where each number comes from.

Built With

Share this project:

Updates

Submission history