Tell Me WHY Application Development by Julia AkinciTell Me WHY Application Development by Julia Akinci

Tell Me WHY Application Development

Julia  Akinci

Julia Akinci

πŸ”Ž Tell Me WHY β€” who failed here before you, and why?

Before you sign the lease or take the shift, see who failed here before you, and why.
Every business that closed at an address, checked twice, with the reasons as evidence-backed hypotheses. Every company behind a venue, and whether it is still alive. Code finds every fact, Gemini explains them, and a second check makes sure a "closure" isn't just a new company behind the same restaurant.
Β· Built for Encode London Hackathon 2026 β€” track: The Real World Β· MongoDB Atlas + Google Gemini (gemini-4-argon)
🎬 Demo video (3 min): https://www.youtube.com/watch?v=xyGk52dv0rI πŸ“Š Pitch deck: Google Slides 🌐 Live app: https://tell-me-why-henna.vercel.app

1. The lease that couldn't work

We signed for a unit. It looked right: good street, fair rent, a restaurant had been there before. Nobody told us it did not have the permissions our concept needed. We found out after signing β€” and finding out cost us a lot of money.
That is how small business owners learn this: the hard way, one lease at a time. Chains pay consultants and location-intelligence platforms ("price on request") to see this. A first-time owner has the landlord's agent β€” the side that wants the deal signed.
Tell Me WHY helps you choose the right place: who was here before you, what went wrong for them, and what to check about the space before you sign.

2. The shift that was never paid

I wasn't paid for my work. The company that employed me had been dissolved β€” and I didn't know. The restaurant kept trading. The owners simply moved it to a new company and carried on. Other people kept coming in for extra shifts, not knowing they would never be paid either: their employer, on paper, no longer existed. The only trace is in Companies House β€” if you know to look, and know what you're looking at.
Tell Me WHY lets anyone check a venue before the first shift: has the company behind it changed, did the old one disappear while the venue kept trading, and what to ask before you start.
Why me: 15+ years in hospitality, 7 venues opened in several countries β€” and both of these happened to me.

Two people, one investigation board

πŸͺ "I'm opening a venue"
πŸ§‘β€πŸ³ "I'm taking a job"
Asks
Who failed at this address before me, and why?
Is the company behind this venue still alive?
Enters
a street, address or venue name
a venue name
Gets
a map of closures + a case file per address: the chain of companies, how long each lasted, whether the closure is confirmed, 2–3 hypotheses for why with evidence, confidence and a counter-argument
a traffic light with signals from public records, questions to ask before the first shift, and where to get help (Acas, HMRC, Redundancy Payments Service, Citizens Advice)
Traffic-light rule (worker mode): 🟑 needs verification for anything inferred from company changes β€” it is a signal, not a fact. πŸ”΄ only when Companies House confirms an insolvency procedure (liquidation, administration, receivership). 🟒 when our data shows no signals, which is not a guarantee.
A real case file β€” 14 Rivington St, Shoreditch (210 m from Encode Hub). Dates are the companies' registration and dissolution, not the venues' trading life β€” we never present one as the other:
Nanashi Shoreditch Ltd Β· company 2017-11 β†’ 2021-05 (42 months) Β· venue closed permanently β€” Google, rated 4.5 (285 reviews)
Chingu Ltd (Korean fried chicken & ramen) Β· company 2024-03 β†’ 2026-01 (22 months) Β· venue temporarily closed β€” Google, rated 4.6 (18 reviews)
Around it: 85 venues on Google within 150 m, neighbours' median rating 4.5, Old Street station 380 m
Gemini's headline: "Two consecutive well-rated Asian dining concepts closed at 14 Rivington St within 22–42 months amid fierce local competition." Every hypothesis cites the numbers above and comes with a counter-argument.
A real employer check β€” Schnitzel Heaven, 57 Pitfield St: 🟑 needs verification β€” three food companies registered at the address since 2019 (two of them look like venues); the latest one was dissolved in Sept 2026 while the venue still trades (FSA + Google). For staff: ask who your employer is on paper.

What you see

Eight screens, light and calm, built mobile-first (people open it from a QR code in the room):
Home β€” "Before you sign, know the story." One search box, two modes: I'm opening a venue / I'm taking a job.
Open a venue β€” pick a concept (coffee shop, bakery, restaurant, takeaway, bar) and a street, address or postcode. You get how many direct competitors are within 200–500 m, how high the competition is compared with the rest of the neighbourhood, the typical price per person, the rating and hygiene bar to clear, who eats around there, and the case files nearby. With no concept chosen, it shows what trades around the place.
Address case file β€” In short first: the venue today, the most likely reason and the case against it, questions for the landlord. Then the companies at the address, each verified; possible reasons with evidence and counter-arguments; and, folded away, Will the space work for your concept?, the street by the hour and the street over the years.
Take a job β€” pick a trading venue on the map (or Near me, or by name). It names the likely legal employer (the active company matched to the venue) with its Companies House number to check against the contract. If a company behind it was dissolved while the venue trades on, a plain fact card says so; then what the shifts may look like, four questions to ask, and where to get help (Acas, Redundancy Payments Service, HMRC, Citizens Advice).
Closures map β€” every case file on the map, for Shoreditch & Hoxton or Richmond & St Margarets, filtered by Closure confirmed Β· Likely closure Β· Unverified Β· New company, same venue.
Ask the analyst β€” a question in plain words; Gemini answers with MongoDB tools and shows every query.
Venue report (venue.html) β€” one page per cafΓ©, restaurant or bar (1,102): Google rating and reviews, FSA hygiene, price, who runs it (every food company at the address or under its trading name, active and dissolved, with dates β€” found for 400 venues β€” and the likely operator where the match is strong, 98 so far), what guests praise and criticise (Gemini, every quote checked), who comes, opening hours and what it offers, its direct competitors within 300 m on a map and in a table, the neighbourhood mix, the street by the hour and over the years, and what closed nearby.
Near you (here.html, the QR code in the room) β€” no typing: the case files within a short walk of Encode Hub.
"Will the space work for your concept?" A previous restaurant is not proof that yours is allowed. The case file separates three checks β€” lawful use class (old A-classes vs. today's Class E), installed extraction, and suitability for your equipment β€” and changes the questions for a coffee shop, a bakery with on-site baking or a hot kitchen. Each stays Not verified / Assessment needed until documents exist; official guidance (GOV.UK, Planning Portal, HSE, Hackney) is linked.

How it works

Collect. Active and dissolved food & drink companies (SIC 56xxx) from Companies House, all food businesses from the FSA hygiene register, venues with hours, prices and reviews from Google Places, stations from TfL, demographics from ONS Census 2021. Everything goes into MongoDB Atlas.
Group by address into chains: who traded here, in what order, for how long. Addresses with more than six companies (accountants, registered-office services) are dropped.
Verify every company (scripts/verify_closures.py) β€” see below.
Compute context in code: nearest station, venues within 150 m, share of neighbours open after 21:00 and on Sundays, neighbours' median Google and hygiene ratings.
Gemini writes hypotheses over those facts only, as strict JSON: headline, 2–3 hypotheses (each with evidence, confidence and a counter-argument), the chain pattern, and a caveat.
The app reads case files from a snapshot (app/data/), so pages open without waiting on the database. Live questions go to Atlas through Vercel functions: competitors and venue reports (/api/venue), Ask the analyst (/api/ask) and the live closure (/api/demo-closure, /api/live).

Verify, then explain: why we don't trust a dissolved company

Restaurants change the company behind them all the time: new partners, tax, restructuring. If we called every dissolved company a closure, the board would be full of "failures" that are still serving dinner. So every company in every chain is checked against the real world before it counts:
Is a venue with the same name trading within 45 m right now? (FSA + Google in our database)
If not, ask Google Places by name near the address: is it CLOSED_PERMANENTLY, CLOSED_TEMPORARILY or OPERATIONAL? (results cached, so re-running costs nothing; --refresh re-checks)
We check the 146 companies registered at the 112 case-file addresses. Most of the 6,544 dissolved food & drink companies we loaded sit elsewhere, often at accountants' and registered-office addresses.
Each address then gets a label that describes its history, not the venue today: Closure confirmed (3) Β· Likely closure (31) Β· Unverified (67) Β· New company, same venue (11). The venue's status today is shown separately. The same verdict means different things to different people: for a tenant, operating_now is good news (the place survives); for a worker, it is a red flag (the employer company is gone while the venue trades on).

How we use Google Gemini

Model gemini-4-argon via the Gemini API
1 Β· Case files
turns a fact sheet about one address into a case file: headline, hypotheses with evidence / confidence / counter-argument, chain pattern, caveat. Structured output (responseMimeType: application/json + responseSchema), temperature 0.3 β€” scripts/gen_reasons.py
2 Β· Guests' own words
reads reviews and returns quotes for each customer segment and what guests praise or criticise; every quote is checked word for word by code. Structured output, temperature 0.1 β€” scripts/gen_audience.py, scripts/gen_review_themes.py
3 Β· Ask the analyst
a live agent: function calling over three MongoDB tools, it decides what to look up and cites case files. Temperature 0.2 β€” api/ask.js

One card per venue: FSA and Google merged

The hygiene register and Google Places describe the same places under different names (YAYACAS vs YAYACAS Authentic Greek Restaurant). In Shoreditch & Hoxton, scripts/build_venues.py merges them by similar name within 60 m (274 venues), searches Google by name for FSA venues without a match (47 found) and asks the free FSA API about Google-only venues (116 found). Result: 851 food & drink venues around Encode Hub, 409 with both a Google rating and an FSA hygiene score; the rest say honestly what is missing. With Richmond & St Margarets, 1,102 venues. Each venue gets a concept from its primary Google category, FSA type and name β€” a cinema with a cafΓ© counter is not a coffee shop.

Day or evening, and how many people? Open data instead of paid footfall

Many first-time owners learn too late that the street empties after 18:00 β€” and that daytime trade alone won't pay the rent. Real footfall counters (Huq, MyTraffic, Placer.ai) are paid, so we use open proxies and say so:
The street by the hour (scripts/gen_hours.py): opening hours of every trading venue within 150 m, counted hour by hour for weekdays and weekends. At 57 Pitfield St, 9 of 10 neighbours are open at 13:00 and 6 at 21:00.
People through nearby stations (scripts/gen_footfall.py): TfL Annual Station Counts 2025 β€” Old Street, 430 m away, has 57,204 entries and exits on a typical weekday and 41,011 on a Saturday β€” plus the station's typical busyness by hour from the TfL Crowding API.
Previous occupants' own hours are shown only where Google kept them (closed listings usually lose them).
Labelled on screen: people entering and leaving stations, not people walking past this door; venue counts show who is open, not how busy they are.

Who are the customers? Code first, quotes checked

Each of the 1,107 Google venues in Shoreditch & Hoxton gets up to three customer segments (office workers, evening crowd, families, regulars, visitors, remote workers, students) as a hypothesis with confidence:
Code reads opening hours (closed at weekends β†’ office trade; open past 23:00 β†’ evening crowd), Google attributes (good for children, weekend brunch, dinner with beer and wine, budget prices) and the ONS Census 2021 area around the venue.
Gemini reads the reviews and returns guests' own words for each segment ("…with my team, 14 of us in total"). Every quote is checked by code against the review text; a quote that isn't there word for word is dropped (1,103 kept, 2 rejected).
High confidence only when code and reviews agree. Weak signals are labelled as such and never called "main".
The same data, shown differently to each person: the tenant sees who eats around here; the worker sees what the shifts may look like. Script: scripts/gen_audience.py.

Why the model can't make things up

It never sees raw data and never counts. It gets a fact sheet the code already computed: the chain with dates and lifespans, each company's verification verdict, the context numbers, who trades nearby now.
Facts only. The prompt forbids anything outside the fact sheet; we have no reviews for closed places, and the model is told so.
Every hypothesis must cite facts (a number or a name from the sheet) and must carry a counter-argument.
Verdicts it must respect: operating_now is never called a closure; unclear is never called a closure; confidence can't be high unless a closure is confirmed by Google.
Registered-office trap: if lifespans look templated or names don't look like venues, the model must lower confidence and say so in the caveat.
A reason is a hypothesis, not a fact. These are real, named businesses. The prompt forbids words that suggest wrongdoing (phoenix, restructuring, debt, insolvency, fraud…) and code checks every answer; an answer that breaks the rule is regenerated with the words named, and a hypothesis that still breaks it is dropped.
⏳ Not yet: automatic post-checks of every number in the output and a blind evaluation against a code-only template (the approach that worked in my previous hackathon project). Planned next.

How we use MongoDB Atlas

Repository structure

design/ the site: pages, styles, plan.js (Open a venue, Ask the analyst, venue report, live alerts), assets app/ data snapshot (data/) and shared logic (lib/employer.js, also used by the API) api/ Vercel functions: on Atlas β€” venue, ask, demo-closure, live; on the snapshot β€” case, cases, employer-check docs/ API contract, front-end components, diagrams scripts/ data pipeline, one script per step (see scripts/README.md)

How we built it

Solo build. Product, data decisions and hospitality know-how: Julia. Code and data pipeline written with Claude Code; design prototype made with ChatGPT. Every number in this README was checked against the data.

License

MIT Β© 2026 Julia Zabrodska

About

Before you sign the lease or take the shift, see who failed here before you β€” and why. London hospitality, public records, MongoDB Atlas + Gemini. Encode London Hackathon 2026.
Like this project

Posted Oct 29, 2026

Developed 'Tell Me WHY' app to assess venue and employer risks in hospitality.

Likes

0

Views

2

Timeline

Jun 1, 2026 - Ongoing