case-studyuser-storyarchitecture

Case Study: How a Non-Developer Built a Dining Micro-App Using Claude and Claude Code

hhiro

2026-02-06

11 min read

How a non-developer built a dining micro-app with Claude and Claude Code—prompts, architecture, data sources, security, and scaling lessons.

Hook: Why this case study matters to busy engineering teams

Decision fatigue, tight deadlines, and the pressure to ship AI features fast — sound familiar? In 2026 the dominant question for technology teams is no longer "can AI help?" but "how do we reliably integrate it with predictable cost, latency and security?" This case study shows how a non-developer built a dining micro-app using Claude and Claude Code, and it explains the exact prompts, architecture, data sources, security trade-offs and the changes you'd make when taking the idea from one user to production-grade scale.

Quick summary (the inverted pyramid)

A non-developer (in the style of Rebecca Yu) built "Where2Eat" in about a week. The app recommends restaurants for a small friend group using a combination of Claude for natural language reasoning and Claude Code for code generation and execution. Core components: a simple frontend, a lightweight backend API, a small vector store for RAG, and third-party place data (OpenStreetMap + Yelp/Google Places). This article explains the full workflow, sample prompts, the Claude Code usage patterns, security decisions, and what you'd do differently at scale.

Why this matters in 2026

By late 2025 and into 2026, tool-augmented LLMs (models designed to call external tools) and developer-focused products like Claude Code made it practical for non-engineers to assemble useful apps quickly. At the same time, teams now require robust MLOps, observability, and cost-control patterns. This case study bridges the two: fast prototyping with strong operational hygiene plans for scale.

User story and goals

The user story was simple and relatable: "As Rebecca, I want a quick app that suggests restaurants for my friends based on our shared preferences, so we can stop arguing in group chat." The acceptance criteria were pragmatic:

Give 3 tailored restaurant suggestions with short rationale
Respect preferences (dietary needs, cuisine, price range)
Work on mobile and desktop (responsive web micro-app)
Be safe with PII, and keep costs under a modest budget

Architecture — minimal, extensible, production-aware

The architecture deliberately stayed lightweight so a non-developer could assemble it, yet it followed patterns that scale.

Core components

Frontend: Static single-page app (Svelte) hosted on CDN for low cost and fast load.
Backend API: Small serverless function (FastAPI or Node/Express on Cloud Run) that handles authentication, orchestration of Claude/Claude Code calls, and rate limits.
Vector store: Pinecone/Weaviate/Chroma (hosted) to cache embeddings for restaurant descriptions and past user sessions.
Place data: Hybrid approach: primary source OpenStreetMap for open licensing + optional enrichment from Google Places or Yelp APIs for ratings and photos.
Model layer: Claude for reasoning and recommendation; Claude Code for generating small server-side functions or transformation scripts at runtime.
Observability: Lightweight metrics (Prometheus/Grafana or managed equivalent) and structured logging (JSON logs) for LLM request latency, token usage, and error rates.

Why Claude + Claude Code?

Claude excels at safe, instruction-following reasoning and context-sensitive task breakdowns. Claude Code adds the ability to author and execute short code snippets—ideal for a micro-app that needs on-the-fly data transformations without a heavy engineering lift. In 2026, Claude products have improved tool-use reliability and built-in safety constraints, making them practical for prototypes and internal tools.

Data sources and design decisions

Choosing data sources involved balancing cost, freshness, and privacy.

Primary data sources

OpenStreetMap (OSM): Free, open-license place location and POI data; used for core location filtering and types (restaurant, cafe, etc.).
Google Places / Yelp (optional): Used for enriched ratings, business hours, photos. Pulled only when needed to limit cost.
User preferences: Stored locally in encrypted storage on the serverless function (encrypted at rest). Minimal PII: names and simple preference tags.
Session history: Embeddings of past conversations and chosen restaurants in the vector store for personalization.

Why a hybrid approach?

Open data keeps cost down and reduces vendor lock-in. Enrichment APIs are used sparingly to avoid heavy bills and compliance complexity — a pattern many teams adopted in late 2025 when public API rate limits tightened.

Prompt design — the heart of the micro-app

Good prompts make the app feel intelligent while controlling cost and behavior. Below are the exact prompt patterns used and why they work.

1) System prompt (Claude)

{
  "role": "system",
  "content": "You are Where2Eat, a concise restaurant recommender. Return exactly three options with a one-sentence reason each, plus a short JSON block with {id, name, lat, lon, reason}. If preferences conflict, propose a compromise. Never invent exact opening hours or phone numbers; if unavailable, say 'unknown'. Keep answers concise and neutral."
}

Why: Limits verbosity, enforces JSON for programmatic parsing, and prevents hallucinated facts (a common failure mode in 2024–2025 that improved but remains possible in 2026).

2) User prompt (example)

{
  "role": "user",
  "content": "Group: 4 friends. Preferences: two vegetarians, one likes spicy food, another wants vegetarian-friendly sushi. Budget: $$. Location: 40.73061,-73.935242. Distance: 15 mins by car. Cuisine avoid: fast food. What's a good place to go?"
}

Why: Structured natural language that includes constraints helps Claude avoid under-specification.

3) RAG step — building the context

Before sending the user query to Claude, the backend performs a small RAG (retrieval-augmented generation) process:

Query vector store for restaurants near the location.
Attach the top 5 candidate place snippets (name, short desc, rating if available) to the prompt as context.
Send to Claude with the system prompt above.

This reduces hallucinations and improves factual accuracy while keeping token usage manageable.

4) Claude Code usage

Claude Code was used for two tasks:

Data transformation: Generate a small function to normalize returned place data into the app's schema (id, lat, lon, price_level, tags).
Session summarization: Create short session summaries for storage as embeddings to improve personalization.

Example Claude Code exchange (pseudo-API):

// Request to Claude Code:
{
  "task": "Generate a JavaScript function that maps raw place objects from Google/Yelp/OSM to {id,name,lat,lon,price_level,tags}. Handle missing fields gracefully and return null for coordinates if absent. Keep function under 40 lines."
}

// Claude Code returns executable JS which the backend runs in a sandboxed environment to transform data.

Why: This offloads small ETL tasks to a model instead of hand-coding every transformation. For a prototype this cuts time dramatically. For scale, generated code must be reviewed or removed in favor of static, unit-tested code.

Security, privacy and compliance decisions

Even as a personal micro-app, several deliberate security moves were made to avoid bad habits at scale.

Key decisions

Secrets management: All API keys (Claude, Places APIs) live in a secure secret manager (AWS/Google Secret Manager) and are rotated regularly.
PII minimization: Store only preference tags and friend nicknames. No phone numbers or emails unless explicitly added later with consent.
Data residency: For users with stricter compliance needs, the system supports disabling third-party enrichment so all data stays in the app's region.
Model output filtering: Post-process model answers with a safety filter to remove profanity and privacy leakage. Claude's built-in safety reduces risk, but defense-in-depth matters.
Execution sandboxing: When using Claude Code to generate code, run it only inside a time-limited sandbox with no network access by default. Promote to production code after manual audit.

Auditability and observability

The backend logged each model request with request hashes (no raw user PII) and token counts. This allowed cost attribution, latency tracking, and audit trails without exposing sensitive content.

Deployment & MLOps: from prototype to reliability

The initial deployment was serverless and cheap. As usage stabilized, these steps were taken to ensure reliability:

Introduce request-level timeouts and retries for model calls (circuit breaker pattern).
Use a cheaper small Claude model for intent classification and routing; reserve the larger Claude for final recommendation generation.
Cache deterministic model outputs for identical queries for 24 hours to prevent repeat charges and improve latency. See the micro-app playbook for caching strategies.
Use feature flags to gate experimental prompt changes and Claude Code usage.

Performance, cost and optimization

Cost control was a priority. Here are the practical levers used in 2026 that worked well:

Model tiering: Use tiny/fast models for classification, mid-tier for generation, reserve largest for complex reasoning.
Token budgeting: Enforce maximum input and output token lengths. Summarize long sessions into short embeddings before sending to the model.
Selective enrichment: Only call paid enrichment APIs when the top candidate needs more info (e.g., user asked for photos).
Batching: Batch embedding requests and run them during off-peak to save on concurrency costs.

Concrete prompts and examples (copy-paste-ready)

Below are two short, practical prompts used in the prototype.

Recommendation prompt (final payload)

{
  "system": "You are Where2Eat, a concise restaurant recommender. Return exactly three options with one-sentence reasons and a JSON array. Do not invent facts.",
  "context": "[Top 5 retrieved place snippets]\n",
  "user": "Group: 4. Preferences: vegetarian-friendly, spicy; budget $$; avoid: fast food. Location: 40.73061,-73.935242; travel: 15 min by car."
}

Claude Code prompt to normalize places

{
  "task": "Write a JS function normalize(place) that returns {id,name,lat,lon,price_level,tags} or null. Keep under 30 lines and handle missing lat/lon."
}

Lessons learned — what worked and what failed

This section contains the practical lessons that matter to engineering teams planning to build similar features.

Wins

Fast iteration: A usable app in a week—great for prototyping and product validation.
High perceived intelligence: Combining RAG with tailored prompts made recommendations feel context-aware.
Low initial costs: Serverless hosting + OpenStreetMap kept expenses tiny while still offering a polished experience.

Pain points

Claude Code risk: Generated code occasionally included assumptions about input shapes that needed manual review.
Data freshness: Relying on cached OSM data occasionally returned closed restaurants; enrichment APIs were needed for freshness but increased cost.
Personalization complexity: Storing too much session data without schemas made embeddings noisy; we improved results by summarizing sessions before embedding.

What we'd do differently at scale

Replace runtime-generated code (Claude Code) with vetted, unit-tested code paths for critical data transformations.
Introduce model-usage policies: smaller models for intent and routing, and a quota system per user/team to control runaway costs.
Improve data pipelines for freshness: schedule background enrichment jobs with rate-limiting and change detection rather than on-demand enrichment for each user query.
Formalize observability: structured traces for each recommendation including retrieval hits, model latencies, token counts, and user feedback to compute an empirical ROI metric.
Prepare privacy and compliance playbooks: data retention windows, explicit consent flows for storing anything beyond preference tags, and region-aware deployments.

Sample roadmap for productionizing

If Where2Eat proved product-market fit and you wanted to scale, here is a pragmatic six-month roadmap.

Month 0–1: Harden backend, replace generated code, add rate-limits and secrets rotation.
Month 2: Add comprehensive logging and metric dashboards; introduce feature flags and canary deployments.
Month 3: Implement model tiering and caching; move embeddings to a managed vector DB with replication.
Month 4–6: Integrate user account management, paid enrichment plan, and GDPR/CCPA compliance flows; conduct load testing and cost forecasting.

Final takeaways — tactical advice for teams

Prototype fast, but plan ops early: Micro-apps allow rapid validation, but define your security and observability guardrails from day one.
RAG + strict system prompts: Combine retrieval with constrained system prompts to reduce hallucinations and get consistent JSON outputs for parsing.
Use Claude Code sparingly: Great for prototypes—always gate and audit generated code before promoting it to production.
Model tiering and caching: These are your most effective levers for predictable cost and latency as you scale.
Design for privacy: Minimize PII, offer opt-out, and ensure region-aware deployments for enterprise readiness.

"Micro-apps are a bridge: they let product teams validate ideas quickly while teaching engineers the constraints they must solve to make features production-grade."

Call to action

Ready to ship AI-powered micro-apps with predictable cost and operational controls? If you want the prompt library, Claude Code recipes, and a production roadmap we used for Where2Eat, get the repo and playbook from our engineering kit. Contact hiro.solutions for a hands-on workshop to convert your first micro-app into a scalable service with MLOps, security, and observability built in.

hiro

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.