full-stack product
ChuckSpot
A "should I set up here?" decision helper for NYC food trucks — combines live event, weather, and cost data into a per-event profitability estimate.
The problem
Food truck owners guess where to park and lose money on bad calls. ChuckSpot lets an owner search events in a city/date range, see a live weather forecast per event, and get an estimated order count and net profit tuned to their own truck's cost structure and ticket price, so they can rank opportunities instead of guessing.
The approach
A React 19 + Vite single-page app talks to a Node/Express API. The
feature the UI actually calls today is one endpoint,
POST /evaluate: it fetches events from the Ticketmaster
Discovery API (with an automatic 4-event NYC mock fallback when no API
key is configured, so the app runs end-to-end with zero setup), pulls a
free, keyless weather forecast per event's location and date from
Open-Meteo, and runs a profitability calculation: expected orders from
attendance and a weather-discounted conversion rate, net profit from
expected orders against the owner's own operating cost and ticket price,
then sorts results highest-profit-first.
A separate, more advanced /api/* backend is already built
but not yet wired to the UI: a weighted Go/No-Go decision engine (crowd
size 35%, weather suitability 25%, OpenStreetMap-derived foot traffic
20%, financial viability 20%) that outputs a GO / MAYBE / NO-GO verdict
with generated, human-readable reasons. It's the next integration
milestone, not vaporware. It's fully implemented server-side, just not
reachable from the app yet.
Tech stack
Key features
- Event search by city + date range, with a zero-config mock-data fallback still scored against live weather when no API key is set.
- Live per-event weather folded into a conversion-rate penalty for rain probability and extreme temperatures.
- Profitability estimate tuned to the owner's own operating cost and ticket price, sorted highest-profit-first, rendered as filterable profit/loss cards on a live map overlay.
- Backend resilience by default: in-memory response caching to respect third-party rate limits, request rate limiting, and graceful fallback to neutral data on any external API failure instead of erroring out.
Known limitations. Only POST /evaluate is reachable from the UI — the decision-engine, expenses, and location API families are implemented but unused today. Login/signup is UI-only (no backend session or user database yet). Event attendance figures are heuristic per-category numbers, since Ticketmaster doesn't expose real attendance — that's disclosed in the code comments and README, not hidden. There's no automated test suite, and the app currently only runs as two local dev servers — no deployment yet.
Security notes
This is a product prototype, not a security project, but two things are worth naming: an earlier commit shipped a leaked API key that a later commit explicitly scrubbed from history (real credential-hygiene remediation, not just "we did it right the first time"), and the backend applies basic hardening (rate limiting, request validation) with graceful degradation on every external-API failure path rather than leaking errors.