mapsaistarter-kit

Prototype a location‑aware dining micro app: integrate Maps/Waze, user prefs and a recommendation LLM

UUnknown

2026-02-25

12 min read

Build a location-aware dining micro app: maps discovery, Waze navigation, user prefs, and an LLM scoring layer with runnable Node/JS code.

Prototype a location-aware dining micro app: integrate Maps/Waze, user prefs and a recommendation LLM

Hook: You’re tired of decision fatigue when choosing where to eat, and you don’t want to waste weeks wiring together maps, auth, and a recommendation engine. In 2026, building a focused, privacy-conscious dining micro app that combines mapping APIs, quick user profiles, and an LLM scoring layer is not only feasible — it’s a high-impact way to reduce decision time for yourself or a small group.

The pitch in one line

In this tutorial you’ll get a runnable prototype: a minimal backend (Node/Express), a front-end that integrates Google Maps + Waze deep-links, a user-preferences model, and an LLM-based scoring layer that ranks candidate restaurants using personalized signals.

Why build this in 2026? Trends and context

Micro apps exploded in popularity since 2023–2025 as rapid AI tooling and low-code stacks enabled non-developers to assemble meaningful, private apps for narrow use cases. By late 2025, AI-driven personalization and LLM scoring became standard for recommendation layers. At the same time, mapping ecosystems matured: Google remains the dominant source for places data, Waze is widely used for live-routing and community alerts, and Apple/Google AI partnerships in 2024–2025 pushed on-device personalization and hybrid cloud approaches.

That means a tiny dining app that: (1) finds nearby restaurants, (2) scores them to match user tastes, and (3) offers a quick route/open-in-Waze button is practical, fast to build, and valuable.

Architecture overview (what we’ll build)

Frontend: Minimal HTML/JS that obtains location, shows a list and a map, and opens a Waze or Google Maps route.
Backend: Node.js + Express endpoints: /search (calls Google Places API), /score (LLM scoring), /prefs (save simple user profile).
LLM layer: Prompt-based scoring via an API (OpenAI/Gemini/Anthropic). It returns numeric scores and rationale for explainability.
User model: lightweight JSON profile with cuisine weights, price sensitivity, and intolerances.

Why combine Maps + Waze?

Google Places gives robust, well-indexed location data and POI metadata — ideal for search and discovery. Waze offers an excellent in-car navigation experience and live incident data. The pragmatic approach in 2026 is: use Google Places for discovery and metadata, then offer a Waze deep-link (or Google Maps route) as the user's navigation option.

Security, privacy and production notes

API keys: Store server-side; never embed secret keys in client JS.
Rate limits: Cache Places search results for a short TTL (30–120s) to reduce cost.
Privacy: Keep user preference profiles small and server-side. In 2026, on-device LLM inference is common — evaluate local models if privacy is a priority.
Licensing: Check Google Places license for commercial use; follow LLM API TOS regarding generated content and data retention.

Minimal runnable prototype — backend (Node.js)

The backend will provide three endpoints: /search, /score, and /prefs. This example uses the Google Places HTTP API and an LLM API via simple fetch calls. Replace placeholders with your own API keys.

// server.js (Node 18+)
import express from 'express';
import fetch from 'node-fetch';
import bodyParser from 'body-parser';

const app = express();
app.use(bodyParser.json());

const PORT = process.env.PORT || 4000;
const GOOGLE_KEY = process.env.GOOGLE_PLACES_API_KEY; // set in env
const LLM_API_KEY = process.env.LLM_API_KEY; // your LLM provider key

// Simple in-memory prefs store (prototype only)
const userPrefs = {
  'user-123': {
    cuisines: { pizza: 1.0, sushi: 0.2, burgers: 0.8 },
    maxPriceLevel: 3, // 0..4
    avoid: ['peanuts']
  }
};

// /search?lat=..&lng=..&radius=1000
app.get('/search', async (req, res) => {
  const { lat, lng, radius = 1000 } = req.query;
  if (!lat || !lng) return res.status(400).json({ error: 'lat,lng required' });

  const placesUrl = `https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=${lat},${lng}&radius=${radius}&type=restaurant&key=${GOOGLE_KEY}`;
  const r = await fetch(placesUrl);
  const json = await r.json();
  // return a trimmed set of fields
  const candidates = (json.results || []).slice(0, 10).map(p => ({
    place_id: p.place_id,
    name: p.name,
    rating: p.rating,
    user_ratings_total: p.user_ratings_total,
    price_level: p.price_level,
    vicinity: p.vicinity,
    types: p.types || [],
    geometry: p.geometry
  }));
  res.json({ candidates });
});

// /score - POST { userId, candidates }
app.post('/score', async (req, res) => {
  const { userId, candidates } = req.body;
  const prefs = userPrefs[userId];
  if (!prefs) return res.status(404).json({ error: 'user not found' });

  // Build a prompt for scoring
  const prompt = buildScoringPrompt(prefs, candidates);

  // Call LLM provider - example generic HTTP call
  const llmResp = await fetch('https://api.llm.example/v1/generate', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${LLM_API_KEY}`
    },
    body: JSON.stringify({
      prompt,
      max_tokens: 300,
      temperature: 0.0
    })
  });

  const llmJson = await llmResp.json();
  const scores = parseScoresFromLLM(llmJson, candidates);
  // merge scores into candidates and sort
  const merged = candidates.map(c => ({ ...c, score: scores[c.place_id] || 0 }));
  merged.sort((a, b) => b.score - a.score);
  res.json({ results: merged });
});

// quick prefs endpoint
app.post('/prefs/:userId', (req, res) => {
  userPrefs[req.params.userId] = req.body;
  res.json({ ok: true });
});

function buildScoringPrompt(prefs, candidates) {
  // Keep prompts compact and structured for reliable parsing
  return `You are a scoring assistant. User preferences: cuisines=${JSON.stringify(prefs.cuisines)}, maxPriceLevel=${prefs.maxPriceLevel}, avoid=${JSON.stringify(prefs.avoid)}. \n
Score each candidate from 0 to 100 for how well it fits the user. Respond in JSON: {"place_id":score,...}. Candidates:\n${JSON.stringify(candidates)}\n
Rules: prefer cuisine weights, penalize exceeding maxPriceLevel by -30, strongly penalize if avoid items appear in name or types. Use rating and user_ratings_total as tie-breakers.`;
}

function parseScoresFromLLM(llmJson, candidates) {
  // Provider-specific parsing goes here. For this prototype, assume the model returns a JSON string in llmJson.text
  try {
    const text = llmJson.text || llmJson.output?.[0]?.content || '';
    const obj = JSON.parse(text);
    return obj;
  } catch (e) {
    // fallback: naive heuristic using rating and cuisine weights
    const fallback = {};
    for (const c of candidates) {
      const base = (c.rating || 3) * 20; // 0..100
      fallback[c.place_id] = Math.round(base);
    }
    return fallback;
  }
}

app.listen(PORT, () => console.log(`Server listening ${PORT}`));

Notes on the server code

Replace https://api.llm.example with your LLM provider (OpenAI, Google Gemini API, Anthropic). Providers changed TOS and formats in 2025–2026, so adapt parsing to the response schema.
The prompt is intentionally structured so the model returns a plain JSON mapping. Use lower temperature to improve determinism.
This is a prototype — use a proper database and auth for production and persist user preferences and caches.

Front-end: Map, list, and Waze deep-links

The front-end handles location permission, lists candidates returned by /search, calls /score to re-rank them, and adds a button to open navigation.

<!-- index.html -->
<!doctype html>
<html>
<head>
  <meta charset="utf-8"/>
  <meta name="viewport" content="width=device-width,initial-scale=1"/>
  <title>Dining micro app prototype</title>
</head>
<body>
  <div id="app">
    <button id="find">Find nearby restaurants</button>
    <ul id="list"></ul>
  </div>

  <script>
  async function getLocation() {
    return new Promise((res, rej) => navigator.geolocation.getCurrentPosition(p => res(p.coords), rej));
  }

  document.getElementById('find').addEventListener('click', async () => {
    const coords = await getLocation();
    const lat = coords.latitude, lng = coords.longitude;
    const r = await fetch(`/search?lat=${lat}&lng=${lng}`);
    const data = await r.json();
    const candidates = data.candidates;

    // score
    const scoreResp = await fetch('/score', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ userId: 'user-123', candidates })
    });
    const scored = await scoreResp.json();

    const list = document.getElementById('list');
    list.innerHTML = '';
    for (const item of scored.results) {
      const li = document.createElement('li');
      li.innerHTML = `${item.name} — ${item.vicinity} — Score: ${item.score}`;
      const openBtn = document.createElement('button');
      openBtn.textContent = 'Open in Waze';
      // Waze and Google Maps deep links
      openBtn.onclick = () => {
        const lat = item.geometry.location.lat;
        const lng = item.geometry.location.lng;
        // Waze URL scheme
        const wazeUrl = `https://waze.com/ul?ll=${lat},${lng}&navigate=yes`;
        window.open(wazeUrl, '_blank');
      };
      li.appendChild(openBtn);
      list.appendChild(li);
    }
  });
  </script>
</body>
</html>

Embedding full turn-by-turn navigation into a micro app increases complexity and licensing friction. A deep-link to Waze or Google Maps delegates the navigation session to the app the user already trusts — minimal friction and maximum reliability.

LLM scoring: design patterns and prompts

LLM scoring is the differentiator. Rather than hard-coding dozens of heuristics, you can use the LLM to synthesize signals: cuisine affinity, proximity, price, ratings, recency, and user-specific constraints.

Design pattern: structured prompt + JSON output

Structured context: Provide the LLM with a small JSON context (user prefs, compact candidate fields).
Concrete instructions: Ask for a numeric score (0–100) and a one-line rationale for each candidate.
Deterministic settings: Use temperature 0–0.2 and low top_p for reproducible results.
Validation: Parse and validate the JSON output. Have a fallback scoring heuristic if parsing fails.

Example prompt (compact)

Score each candidate 0–100 for user with cuisines weights and maxPriceLevel. Output JSON: {"place_id": {"score":N, "reason":".."}, ...}.

Prompt engineering tips (2026)

Include example outputs in the prompt (1–2 examples) to reduce hallucinations.
Use the provider's function-calling or structured output features if available — many LLM APIs in 2025/2026 support direct JSON outputs.
For privacy-sensitive apps, consider on-device LLM inference (quantized LLMs) to avoid sending location/preferences to cloud LLMs.

User profile model — keep it small and useful

For a micro app, less is more. A compact profile that matches real-world decision criteria works best:

{
  "cuisines": {"italian": 1.0, "japanese": 0.3, "mexican": 0.2},
  "dietary_restrictions": ["peanuts"],
  "maxPriceLevel": 2,
  "distanceToleranceMeters": 2500
}

Store a lightweight version server-side and optionally allow the user to keep a local copy on their device for faster personalization and privacy.

Edge cases and improvements

Group decisions: Merge multiple user prefs by weighted averaging and then ask the LLM to explain trade-offs. For small groups (2–6 people) this works reliably.
Cold start: Default profiles based on quick preference onboarding (“I like spicy food”, “budget conscious”) reduce friction.
Allergy detection: Use LLM to flag risky menu keywords, but warn users that accuracy is not guaranteed — always verify with the restaurant.
Offline mode: Cache last-known candidates and do local scoring using a small heuristic if no network or LLM access is available.
Explainability: Save the LLM rationale per recommendation for auditability; in 2026 consumers expect transparency for AI-driven decisions.

Performance and cost control

Batch candidates: Limit to top 10–15 results from Places before scoring to reduce LLM calls.
Cache LLM outputs: If a user repeats similar searches, reuse recent scores for a short TTL.
Hybrid approach: For heavy usage, run a small local model to pre-filter and only call a larger cloud LLM for final ranking.

Real-world example — how a 3-day prototype can be built

Day 1: Wire Google Places search, create a tiny user prefs UI, and show candidate list. Day 2: Add LLM scoring and structure prompts to return JSON. Day 3: Add Waze deep-links, polish explainability (one-line rationale), and add caching and basic error handling.

That workflow mirrors how micro app creators built quickly in 2023–2025; by 2026 the tooling is even smoother, with turnkey LLM SDKs and improved map APIs.

Operational considerations: data, ethics, and legal

Data retention: Consider deleting LLM prompts and outputs related to users after a TTL to reduce privacy exposure.
Bias and fairness: LLMs can reflect biases in training data. Test with a diverse set of profiles and manually inspect outputs.
Transparency: Show users why a place was recommended — e.g., "High match to your Italian cuisine preference; low price" — and provide an option to turn off AI personalization.
Provider contracts: By 2026, many LLM providers require explicit consent for sending sensitive PII. Avoid sending raw user identifiers and precise home address unless necessary.

Advanced strategies and future-proofing (2026+)

On-device LLMs: For privacy-first micro apps, run a quantized LLM on-device for scoring. This reduces cloud costs and keeps personal data local.
Real-time features: Combine Waze incident data with Places popularity trends to avoid places with temporary closures or long waits.
Multimodal signals: Use short image embeddings (photos of menus) to identify likely cuisines or dietary tags when structured data is missing.
Continuous learning: Allow the model to adapt per user from explicit feedback (thumbs up/down) but keep this on-device or encrypted server-side to respect privacy.

Case study: group-of-four quick decision

Scenario: four friends want a place within 20 minutes. Each person supplies quick sliders for cuisine and price. The app aggregates, runs LLM scoring, and returns three top choices with short rationales. The group taps one choice and opens Waze. This flow reduces the minutes-long chat veto cycle into a 90-second decision — exactly the value micro apps aim to deliver.

Debugging tips

Log the LLM prompt and response for failed parsing to iterate on prompt design.
Sanitize and limit the candidates chunk size if the places payload grows unexpectedly.
Test on different devices and networks — deep-links behave differently in mobile browsers vs. desktop.

Summary — what you should have after following this guide

A working Node.js prototype that queries Google Places and exposes a /score endpoint.
A front-end that gets location, lists results, calls the scoring endpoint, and opens Waze/Google Maps.
An LLM prompt pattern that returns structured scores plus rationale, with fallback heuristics.
A minimal user preferences schema to personalize recommendations.

Actionable takeaways

Start small: Limit candidates to 8–12 results for fast scoring and low cost.
Use structured outputs: Ask the LLM for JSON to simplify parsing and auditing.
Delegate navigation: Open Waze or Google Maps via deep-link rather than embedding navigation.
Protect privacy: Consider on-device scoring or minimal context sent to cloud LLMs.

Final thoughts

Micro apps are still winning in 2026 because they solve a single, painful problem with minimal scope. By combining robust map data for discovery, Waze for navigation, and an LLM scoring layer for personalization, you can build a dining recommendation micro app that feels smart, fast, and trustworthy.

Start with the prototype above, iterate on your prompts and user model, and prioritize privacy and explainability. The payoff is a small product that saves real time — and that’s precisely the appeal of micro apps.

Call to action

Try the prototype: clone the repo, set your API keys, and run the server locally. If you want a walkthrough or an extended version with group consensus and on-device scoring examples, sign up for the codenscripts.com newsletter or open an issue on the sample repo — I’ll help you iterate it into a production-ready micro app.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.