Before You Build
Web AppShut Down

Dinnr

Dinnr was a same-day recipe-ingredient delivery service. Its shutdown shows how survey enthusiasm and friendly interviews can look like demand while real orders reveal that the problem is not urgent enough.

View original story

Product snapshot

What it was

Dinnr offered recipe selection and same-day delivery of pre-measured ingredients with cooking instructions.

Who it was for

Busy consumers who wanted to cook at homeEarly adopters of recipe kits and food deliveryPeople who liked cooking but disliked planning and shopping

Problem / value

It removed recipe planning, grocery shopping, and measurement from home cooking while preserving the experience of cooking.

Core workflow

A customer selected a recipe, Dinnr prepared and delivered measured ingredients, and the customer cooked the meal at home using the included instructions.

Core dependency

The model depended on real purchase intent, repeat orders, local delivery operations, gross margin, and customer acquisition cost.

Product form

Recipe-selection websiteSame-day ingredient delivery operationPre-measured ingredient packsPrinted cooking instructions

Pricing model

Public sources describe the product and funding but do not disclose average order value, delivery fees, gross margin, repeat rate, or acquisition cost.

Competitors or alternatives

Grocery deliveryMeal kitsRecipe websitesRestaurant deliveryHome cooking routines

What happened

Summary

Dinnr shut down after encouraging pre-launch research failed to translate into real order volume for same-day recipe-ingredient delivery.

Outcome

The company shut down rather than continue operating a same-day ingredient-delivery model with weak purchase behavior.

Core risk

Stated interest and friendly feedback did not prove urgent, paid demand for a physical delivery workflow.

Timeline

  • Dinnr launched in September 2012 after surveys, alpha testing, and interviews suggested demand.
  • The founder reported 3 orders on launch day and 12 orders in the first week.
  • The founder ended Dinnr on January 12, 2014 after deciding not to accept a small second investment round via Seedrs.
  • He later wrote that Dinnr had not solved a real enough problem.

Before you build

Why it matters

People often say they would use a product when the idea sounds useful. Real demand appears when they pay, repeat, or change behavior without being coached.

Primary check

Before building from survey results, interviews, waitlists, or alpha feedback, test the real buying behavior: paid checkout, repeat use, delivery cost, and whether customers already spend time or money solving the problem.

Checklist

  • Run a real checkout test before building operations.
  • Ask interviewees how they solve the problem today.
  • Measure repeat orders from the first cohort.
  • Test one delivery zone before expanding.
  • Track gross margin after ingredients, delivery, refunds, and support.
  • Have target users paid or deposited, not just said yes?
  • Do customers already spend time or money on the problem?
  • What happens in the first week after launch?
  • Do users order again without incentives?
  • Does margin survive delivery and support cost?

Relevant if

  • You are relying on surveys, interviews, waitlists, or alpha feedback.
  • Your product makes an annoying task more convenient but may not solve an urgent pain.
  • Your product needs operations, inventory, delivery, or support before demand is proven.

Less relevant if

  • You already have repeat paid usage from the target segment.
  • The workflow is mandatory, budgeted, and already solved with paid alternatives.

Pre-build tests

  • Paid preorder for a single delivery day
  • Concierge ingredient delivery pilot
  • Deposit-based recipe kit test
  • Repeat-order cohort test

Transferable lessons

  • Ask about current behavior and spending, not only future intent.
  • Follow surveys with paid checkout or deposit tests.
  • Treat first-week orders and repeat use as stronger evidence than compliments.
  • Launch a thin version before operations get expensive.
  • If a product is convenient rather than urgent, validate repeat frequency early.