TwinTrack

Inspiration

Small business owners make high-stakes decisions - raise prices, open a second location, shift marketing to a new demographic - with almost no data. They can't afford consultants. They don't have analysts. They go on gut feel, and half the time it costs them. We wanted to give a Plano bakery owner the same decision-making firepower that a Fortune 500 company has: a model of their own business that they can stress-test before committing real money to a real decision. That's the digital twin concept - and we asked ourselves, what does that look like for a $15k/month bakery, not a $15B enterprise?

What It Does

TwinTrack lets a small business owner register their business as a digital twin - a structured financial snapshot - and then run what-if simulations against three scenarios: pricing changes, target audience shifts, and franchise expansion. Under the hood, every simulation pulls live economic data from five federal and commercial APIs (FRED, BLS, BEA, Census, NewsData), computes price elasticity from current CPI trends, models footfall and revenue delta, and runs a 12-month ARIMA projection. Claude Haiku enriches the pipeline in three places: resolving ambiguous business types to NAICS codes, extracting structured parameters from plain-English descriptions, and generating a plain-English recommendation grounded in the actual numbers. The output is two financial scenarios - control vs. experiment - with a verdict: proceed, proceed with caution, or avoid.

How We Built It

We split into two tracks and kept a shared JSON schema as the contract between them. The backend is a pure Python ThreadingHTTPServer - no framework. The pipeline flows through four layers: a data fetcher that hits five APIs in parallel with per-series error isolation, a market snapshot builder that combines economic indicators into a single context object, a simulation engine that separates fixed vs. variable costs and models each use case independently, and an LLM layer using Claude Haiku for the three enrichment steps. All intermediate outputs are written to disk as JSON so any layer can be debugged in isolation. he frontend is React 19 + Vite with no component library - pure CSS. The simulation form is a three-step wizard: business selection + use case, use-case-specific parameters, and an optional natural language supplement that feeds straight into the LLM enrichment layer. The two halves talked over a single POST /api/simulate endpoint that returns { op1, op2, recommendation }.

Challenges We Ran Into

The avg ticket problem was the most stubborn. Our bridge derived avg ticket from product price ranges — which works fine for a coffee shop but gives $49.94 for a bakery that sells both $3.50 pastries and $80 custom cakes. We fixed it by switching to the 25th percentile of the price range and adding an employee-hours sanity cap, but it exposed a deeper truth: the form needs an explicit avg ticket field. Fixed vs. variable cost separation took longer than expected. Early simulations were showing unrealistically large margin drops on small price increases because all costs were scaling with volume. We had to go back and split every cost line into fixed (rent, utilities, loan repayment) and variable (supplies, wages) and propagate that split through all three simulation paths. Break-even blowup — when incremental profit was near zero, the franchising model was producing break-even projections of 85,000 months. We caught it in testing and capped it at 120, but it was a reminder that financial models need guardrails, not just formulas. API resilience — one bad FRED series was aborting all five fetches. We had to refactor to per-series error isolation so a missing data point degrades gracefully instead of killing the pipeline.

Accomplishments That We're Proud Of

Running a real end-to-end pipeline at a hackathon — not a mock, not hardcoded data. When you register Flour & Fold in Plano TX and run a pricing simulation, you're getting actual CPI data from FRED, actual unemployment from BLS, actual consumer spending from BEA, actual business density from Census, and actual local news sentiment. The recommendation Claude writes is grounded in those real numbers, not a template. The cost separation architecture. Splitting fixed vs. variable costs and propagating that through three independent simulation models is the kind of thing that usually gets cut at a hackathon. We kept it because without it the numbers are wrong. The graceful degradation throughout the whole stack - every API call, every LLM call, every file write has a fallback path. The app doesn't crash; it degrades.

What We Learned

Real economic data is messy. APIs time out, series return empty arrays, BEA has a 15-second response window. Building resilience isn't optional when your whole product depends on live external data - it's the product. The LLM layer is most valuable at the boundaries: translating ambiguous user input into structured parameters, and translating raw financial output into a human verdict. Everything in between is better served by deterministic code. JSON files as a persistence layer for a 24-hour hackathon is the right call. A database would have cost us 4 hours we didn't have. Financial models need domain knowledge, not just code. Several of our constants - labor ratios, demographic ticket multipliers, amortization windows - are educated approximations. Getting them right requires F&B sector research that goes beyond what a hackathon allows.

What's Next for TwinTrack

More business types. Right now the sim layer is tuned for F&B. The same architecture extends to retail, services, and hospitality - each with their own elasticity curves and cost structures. Multi-simulation comparison. The data layer already outputs OP files for every run. The next UI milestone is a side-by-side view that loads two experiments and diffs them — so an owner can compare "raise prices 10%" vs. "shift to families" on the same screen. Explicit avg ticket field. The biggest data quality fix on the roadmap. Remove the inference, ask for it directly. Continuous twin updates. Right now the twin is a static snapshot. The vision is a lightweight "log this month's actuals" flow that updates the twin over time, so simulations compare against a live baseline, not a registration-day snapshot. Mobile. The current layout is desktop-first. A stripped-down mobile view - just the sim results and recommendation - would put the verdict in an owner's pocket before they sign a lease.