Personal Maps

Inspiration

Finding a place that's genuinely "for you" is harder than it looks. A star rating tells you a restaurant is popular — it doesn't tell you if it's quiet enough for someone with sensory sensitivities, whether the menu has soft-food options for someone recovering from surgery, or if the entrance actually works for a wheelchair. People managing health needs, dietary restrictions, mobility limitations, sensory sensitivities, chronic conditions, are stuck doing this research manually, place by place, hoping a review happens to mention the one thing that matters to them. We wanted to build something that does that searching for you, and is honest about what it actually knows versus what it's guessing.

What it does

Personal Maps is a chat companion that learns what matters to you, health needs, food preferences, mobility, and interests, and then searches real, live business and review data to find places that actually fit. Instead of just showing you a star rating, it looks for specific signals in the data that match what you told it matters, and tells you plainly when it doesn't have enough information to confirm something rather than guessing. You can ask it things like "find me a quiet restaurant near me" or "somewhere with soft food options," and it works with real listing data and review text pulled live, not from memory.

How we built it

• Frontend: Flutter, targeting web, Android, and iOS from one codebase, a simple, accessible chat interface with a scrolling conversation and text composer.
• Model: OpenAI's gpt-4o-mini, orchestrated through real function/tool-calling so the model decides when it needs to look something up rather than answering from memory.
• Data: SerpAPI for live business search and listing data (name, address, rating, hours), plus a second tool for pulling actual review text so the assistant can point to specific, real feedback instead of just an aggregate score.
• Backend: A lightweight Dart proxy server that holds our API keys server-side, so nothing sensitive ships inside the client app, and so we could route around browser CORS restrictions on the review data provider.
• Guardrails: A dedicated steering document, layered on top of our main system prompt, that draws a hard line between "declared" data (what a business or listing states) and "observed" data (what reviewers actually say), and requires the assistant to say "unknown" rather than infer or fabricate when the data doesn't cover something the user cares about.

Challenges we ran into

• Free-tier limits everywhere. We started on a free open-weight model via OpenRouter, but hit heavy shared rate-limiting mid-build and had to pivot to a paid-but-cheap model to keep development moving.
• API response shapes changing under us. Different search engine parameters on our data provider returned differently-shaped results than we expected, which silently broke our parser until we caught it with a live test.
• CORS. Running on Flutter Web meant our review-data provider's API blocked direct browser calls entirely, which we only discovered once we tried it live, solved by adding our own small proxy server.
• The honest one: reviews aren't a great source for hard accessibility facts. We learned partway through that most reviewers simply don't mention things like wheelchair access, so a demo query asking specifically about accessibility would often correctly come back "unknown," which at first looked like a bug and turned out to be the system doing exactly what we designed it to do.
• Multi-turn context. Early on, follow-up questions referencing something from a previous message didn't have access to the data (like place IDs) needed to act on them, which took some tracing to pin down.

Accomplishments that we're proud of

• A working, end-to-end pipeline: chat → tool call → live business search → live review lookup → grounded response, verified with real API calls rather than assumed to work.
• A genuine trust boundary baked into the assistant's behavior: it will say "I don't know" rather than invent an accessibility or dietary claim it can't back up with real data, which we think is the actually important design decision behind this whole idea.
• Getting a cross-platform Flutter app talking to two external APIs through our own proxy, built and debugged under real hackathon time pressure.

What we learned

• Prompt engineering and tool design matter as much as the model choice, a well-specified steering document is what kept the assistant from confidently making things up when the underlying data was thin.
• Free-tier infrastructure is great for prototyping but comes with real reliability tradeoffs; know your fallback plan before you're on stage.
• The gap between "the data exists somewhere" and "the data is reliably attached to this specific place, in this specific format, for free" is bigger than it looks, this shaped several of our biggest pivots.

What's next for Personal Maps

• Add a real profile-building conversation flow, so the assistant gradually learns a user's needs over time instead of relying on a single message.
• Layer in a dedicated, free, structured accessibility data source (like OpenStreetMap's community-maintained accessibility tags) alongside review text, so hard facts (ramps, restroom access) aren't only dependent on whether a reviewer happened to mention them.
• Persist user profiles across sessions so people don't have to re-explain their needs every time they open the app.
• Expand beyond restaurants to the full range of everyday places — pharmacies, clinics, grocery stores — where health-specific fit matters just as much.

Built With

• claude
• dart
• flutter
• openai
• serpapi