Show HN: Tinder, but to decide what to eat

Original Article ↗ Hacker News Discussion ↗

Overall reaction to the idea

  • Many find the “Tinder for choosing dinner” concept fun, relatable, and nicely executed.
  • Others see the problem as trivial and better solved by simple decision rules or conversation between partners.
  • Some worry that outsourcing minor negotiations to an app may weaken relationship skills; others view it as just another neutral tool, like a shared list or index cards.

UX, content, and functionality

  • Some users report crashes after setting up a “family” group, making the app unusable for them.
  • The requirement to pick 3 out of 4 initial options, with no ingredients shown, is criticized as too constrained and opaque.
  • Manual recipe entry is seen as high friction; several suggest bootstrapping with a large recipe database or integrating with existing tools (e.g., Mealie, cookbooks).
  • Requested features include:
    • Weekly planning, shopping lists, and pantry/fridge awareness.
    • Larger households and non-couple use.
    • Seeing a partner’s likes/favorites, past selections, and popularity/reviews of dishes.
    • Ingredient filters and nuance around “essential” vs “optional” ingredients.

Platform and architecture debates

  • Limited to iOS for now; some ask about Android and suggest a web app or PWA to avoid store fees and broaden reach.
  • Several argue the app could be architected as local-first with no central server (e.g., deep links, QR codes, email sharing), greatly reducing ongoing costs and privacy risks.
  • Others counter that online services inherently have recurring costs and that subscriptions are reasonable from a developer’s perspective.

Pricing, subscriptions, and monetization

  • Strong pushback on $20/year subscription for such a narrow use case; many prefer a one-time ~$5–10 payment, prepaid non-renewing access, or true pay-per-use.
  • Users cite “subscription fatigue” and argue maintenance costs are a business problem, not a justification to rent basic utilities to users.
  • Defenders emphasize predictable revenue, Apple’s annual developer fee, server and maintenance work, and the difficulty of sustaining a low one-time purchase model.
  • Alternative monetization ideas:
    • Ads and sponsored placements from grocers or restaurants.
    • Affiliate/commission on ordering ingredients.
    • A (criticized) suggestion to monetize user data with a paid privacy tier.
    • Keeping it tiny, local-first, and cheap as a side project.

Alternatives and related projects

  • Several describe personal solutions: spreadsheets with randomized menus, custom web apps, self-hosted planners, and rules-of-thumb for picking restaurants.
  • Open-source projects are shared that randomly suggest meals or filter recipes by available ingredients.
  • Some note similar ideas appear frequently and rarely gain lasting traction, often due to content bootstrapping and limited incremental value.