Before You Build
Mobile AppShut Down

Flowtab

Flowtab was a mobile app that let bar and nightclub customers order and pay for drinks from their phones instead of waiting at the bar.

View original story

Product snapshot

What it was

Flowtab let customers order and pay for drinks from a phone at participating bars and nightclubs.

Who it was for

bar patronsnightclub customersbar ownershospitality venues

Problem / value

Reduced line and payment friction for customers and promised smoother ordering for venues.

Core workflow

  • order drinks from a phone
  • pay in-app
  • notify customers when drinks are ready
  • reduce bar-line friction

Core dependency

Dense venue adoption, repeat customer behavior, and reliable in-venue operations.

Product form

iOS appAndroid appbar-facing iPad appmobile payment workflow

Pricing model

Failory reports a per-order customer fee after successful orders; public sources do not show a durable venue subscription model.

What happened

Summary

Flowtab shut down after failing to turn bar-line pain into repeat usage, venue density, and reliable local distribution.

Outcome

Public postmortem reporting describes low order volume, failed acquisition tactics, and doubts about the business model.

Demand signal

Flowtab solved a recognizable moment of frustration, but public sources show that the use case was too situational, order volume was low, and users did not return often enough to create a reliable habit.

Distribution issue

The product needed two-sided local density: enough venues to make the app useful and enough customers inside those venues to matter. Founder-run launch events and subsidies created spikes, not a repeatable acquisition channel.

Timeline

  • Concept began in 2011
  • App launched in February 2012
  • TechCrunch reported 12 active bars by January 2013
  • Product shut down in 2013

Before you build

Why it matters

Flowtab is the kind of app a solo builder might create after one frustrating night out, but the real risk was behavior frequency and local execution, not app complexity.

Primary check

Validate repeat frequency and venue density before building a local ordering app: the pain must happen often enough, in enough participating venues, without founder-run events propping it up.

Checklist

  • Track repeat orders per user by venue.
  • Track order volume when founders are not physically present.
  • Measure staff workload and failure rate during busy periods.
  • How many times per month will the same user naturally need this?
  • How many venues must be live before the customer app is useful?
  • Can staff fulfill orders smoothly during real peak conditions?

Relevant if

  • You are building a local app that depends on participating venues or merchants.
  • The user pain is obvious but happens only in specific places or moments.

Less relevant if

  • Your product has daily repeat usage independent of local supply density.

Pre-build tests

  • Run one venue cluster manually and require repeat use before building generalized POS workflows.
  • Test the workflow during a crowded night, not only during a controlled launch event.

Transferable lessons

  • Measure repeat behavior before building deeper workflow integrations.
  • Validate merchant operations as carefully as customer demand.
  • Treat launch events and subsidies as weak demand signals unless usage repeats without them.

If you build this today

Start with one venue cluster and measure repeat orders per user, order volume per venue, staff workload, and organic acquisition. Do not build broad POS or payment infrastructure until the local loop works without founder presence.