-
-
See the week ahead: local events and ordering deadlines, together.
-
Understand why it matters: relevance, confidence and missing information stay visible.
-
Prepare before the cutoff: connect a nearby event to the supplier decision it affects.
-
Make the final call: review and edit the message before copying it to send.
Inspiration
A café owner needs to decide what to order before they know how busy the next few days will be. A nearby graduation, concert or community event could change demand, but the useful information is scattered across websites and event calendars.
We wanted to connect that information to a practical decision: what should the owner pay attention to, why does it matter to their business, and when do they need to act?
That became Footfall.
What it does
Footfall helps businesses that depend on foot traffic understand nearby events and prepare for possible changes in demand. Our first use case is an independent café in Cork.
The owner can review upcoming insights, open the supporting evidence, and see why an event is relevant to their location and opening hours. Footfall connects that insight to supplier ordering deadlines, then helps the owner prepare an editable supplier message.
The flow is simple:
- Review upcoming local insights.
- Open an event to inspect its source, timing, relevance and uncertainty.
- Check the associated supplier deadline.
- Create and edit a message.
- Approve and copy it for sending.
The owner stays in control. Approving a message does not send it or place an order.
How we built it
We built Footfall with Python and Flask, using a server-rendered interface with HTML, CSS and JavaScript. The hosted application runs on Vercel, with persistent storage provided by Turso/libSQL.
A bounded source refresh fetches pages from a saved directory of local sources. An Azure-hosted language model extracts structured event information, which the application validates before saving.
Python rules handle distance, opening-hour overlap, supplier cutoffs and relevance. This makes the operational decisions explainable: the owner can see why an event was included or excluded.
We preserve source links and supporting evidence, track refresh outcomes, and retain saved records when a source refresh fails. Missing or rejected information remains visible rather than becoming a confident recommendation.
Challenges we ran into
One of the hardest parts was turning event listings into reliable business inputs. Pages vary in structure, dates can be ambiguous, and extracted details need to match the source. We added validation and visible review findings so an incomplete refresh does not look like complete coverage.
Another challenge was relevance. An event being nearby does not mean it will affect a café. Opening hours, location and timing all matter, so we made those checks explicit.
Deploying the application also meant making data persist across requests and handling database connections around longer model calls. We worked through those integration issues while keeping the main user flow small enough to demonstrate clearly.
Accomplishments that we're proud of
We brought the idea through to a hosted application with a complete path from local information to a reviewed supplier message.
We are particularly proud of keeping the evidence close to the decision. Footfall shows the reasons behind an insight, separates potential impact from confidence, and gives the owner the final say.
The interface also works on mobile, so the flow can fit around the day-to-day work of running a small business.
What we learned
Extracting an event is only the first step. The useful part is connecting it to a specific business, a relevant trading window and a decision deadline.
We also learned that uncertainty needs to be part of the experience. A clear explanation of missing information is more useful than a precise-looking prediction that the evidence cannot support.
Building the complete flow early helped us focus our integration work and decide which ideas could wait.
What's next for Footfall
Our next step is to test Footfall with independent business owners in Cork. We want to understand which local surprises affect their decisions, how they monitor them today, and whether our insights arrive early enough to help.
From there, we would expand source coverage, add scheduled refreshes and notifications, and improve business-specific configuration. Secure accounts and subscription billing would follow customer validation.
A subscription service is our proposed commercial direction. Pricing, willingness to pay and financial impact still need validation.
Prototype scope
The walkthrough uses a configured café profile, saved events and source refreshes. Saved records and supplier assumptions should not be treated as independently verified facts.
Impact labels are explainable heuristics, not validated customer or revenue forecasts. Coverage is limited to the monitored sources.
Sign-in and sign-up are simulated. The prototype does not process payments, send supplier messages or place orders.
Credits
Footfall uses Flask, the OpenAI Python SDK, Turso/libSQL and Vercel. Event information is drawn from the source pages linked within the application. Those organisations are information sources, not project partners.
We used AI coding assistance during development and an Azure-hosted language model for event extraction and optional message wording. Application rules validate extracted information and calculate business relevance.
