Restaurant-led · Koreatown · one honest caveat remains visible.
$20–$38 / personHigh confidence
Responsive client-side web application · 2025–2026
Hangout OS
Five quick choices. Three distinct routes to a good night.
Hangout OS is a responsive client-side web application that helps people choose a Los Angeles hangout without opening ten tabs or trusting a black-box recommendation. It combines curated local data, deterministic ranking, and explicit uncertainty in an inspectable five-question flow.
- Product
- Curated Los Angeles planning web application
- Audience
- Friends, couples, families, and solo planners choosing a budget-aware hangout in Los Angeles.
- Role
- Product strategy, interaction design, React implementation, recommendation logic, data modeling, provenance, and release QA
- Stack
- TypeScript · React · Vite · Node.js
- Timeline
- 2025 project · v0.10.0 release review completed July 2026
- Status
- v0.10.0 · Public case study and guided fixture replay are live; the full application remains a local portfolio review build.
Your LA shortlistThree distinct routes to a good night.Five questions · Curated, not live · Required costs are estimates
Place-only · quick effort · locality reviewed.
$14–$32 / personSources reviewed
Event-and-food route with timing and commitment explicit.
$10–$24 / personVerify before going
Current deterministic portfolio-demo state · Curated, not live · Sources reviewed · Guided scenario available
Interface evidence
The reviewed product, shown at desktop and phone widths.
These captures come from the final local v0.10.0 review build. They show the same curated, non-live recommendation experience described in this case study.
Overview
A faster path from preferences to a workable plan.
Planning a group hangout looks simple until budget, location, timing, food, travel, and group fit collide. Most discovery products maximize choice or popularity; Hangout OS is designed to reduce decision friction without hiding tradeoffs or inventing live certainty.
What a visitor does
Answer five selection-based questions, compare the best fit, closest or easiest option, and best value, then explore every other eligible activity, restaurant, pairing, and date-sensitive event without restarting.
Friends, couples, families, and solo planners choosing a budget-aware hangout in Los Angeles.
Five selections lead to three differentiated recommendations and an explorable set of eligible alternatives.
The catalog is intentionally curated and bounded; it does not claim complete Los Angeles coverage or live availability.
System design
Five inputs become a shortlist with visible tradeoffs.
Typed data and deterministic rules filter invalid options, protect required constraints, rank eligible plans, and explain the result.
- 01Five selectionsArea · group · budget · vibe · when
- 02EligibilityActive · all-ages · group · date · environment
- 03Budget protectionConservative high-end cost must fit
- 04Local-first rankingReviewed clusters · preferences · stable ties
- 05Decision surfaceThree leaders · categories · honest stretch picks
Hard limits stay hard
Required constraints filter eligibility. Softer preferences influence ordering, but never quietly promote an invalid plan.
Cost uses the conservative end
Budget checks use required admission, shared parking, and only a named food destination. Generic food estimates never become a promised plan total.
Locality is reviewed, not guessed
Results prioritize the selected area and reviewed nearby clusters. Broader-LA options remain possible only when clearly labeled.
Freshness is part of the interface
Cards retain source-review dates, availability caveats, and official actions because curated data should never look live when it is not.
Evidence
Current QA evidence.
The final local build passed 160 automated tests and 127 browser assertions across the recommendation engine, keyboard and focus behavior, reduced motion, responsive layouts, persistence, media failure states, and overflow.
160passing automated tests
127passing browser assertions
7responsive viewport widths reviewed
0console or first-party resource failures in final QA
What the current build demonstrates
- A five-step mobile input flow that reaches useful results without free-form prompting.
- A stable three-leader decision surface with explainable differences and progressive disclosure.
- Atomic refinements that update only when applied, avoiding a shortlist that shifts mid-decision.
These are catalog and verification signals, not adoption or conversion metrics.
Current limits
What is not live or proven.
The current build distinguishes validated product behavior from public usage, complete coverage, and live information.
Limits
- The catalog is intentionally curated and bounded; it does not claim complete Los Angeles coverage or live availability.
- Venue photography is deliberately partial: 7 of 45 place and activity records and 2 of 19 restaurant records have rights-cleared venue images. Other surfaces use clearly labeled original area artwork or honest no-image fallbacks.
- The evidence demonstrates product behavior and release quality, not user adoption, conversion, or real-world outcome metrics.
- The full product remains a local portfolio review build. The public guided demo replays one verified fixture scenario and does not expose the full catalog or recommendation engine.
Status and next step
Public case study and guided fixture replay are live; the full application remains a local portfolio review build.
Use the public guided demo to make the core decision surface reviewable while keeping the full local application private.
Next
Try the decision surface or review another project.
The guided demo makes the core shortlist hierarchy testable without presenting the curated catalog as live or publishing the full local application.