Before You Build
Mobile AppShut Down

Gulp

Gulp was a college mobile app that let students pay bar cover charges by phone instead of using cash at the door.

View original story

Product snapshot

What it was

Gulp sold digital bar covers that students could redeem at participating bars.

Who it was for

college studentslocal barsbar door staff

Problem / value

Avoid ATM trips and cash cover payments for college nightlife.

Core workflow

A student buys a digital cover, arrives at the bar, and redeems the cover with door staff for entry.

Core dependency

Repeat student purchases, bar participation, door-staff acceptance, and positive margin per cover.

Product form

mobile payment appdigital cover purchase flowbar-door redemption workflow

Pricing model

Users paid the cover plus a convenience fee, but processing fees and acquisition cost left weak margin.

Competitors or alternatives

cash cover paymentsATM withdrawalscard payments at the doorguest lists and bar promotions

What happened

Summary

Gulp was a college-built app for paying bar cover charges by phone.

Outcome

The team processed about $10,000 in cover purchases but averaged less than one purchase per user and ran out of money.

Core risk

Small payment margin and offline redemption friction broke adoption

Shutdown reason

The source points to weak unit economics, low repeat usage, and door-staff workflow friction.

Demand signal

Gulp acquired users, but they were not sticking: the source says the app processed about $10,000 in cover purchases and averaged less than one purchase per user.

Distribution issue

The team could attract students, but adoption depended on bars and door staff reliably accepting digital covers during a noisy offline entry process.

Timeline

  • identified cash cover payments as a student nightlife pain
  • spent about $15,000 building a mobile app in roughly two months
  • tested with 2 of 10 local bars
  • acquired about 2,500 users in one month
  • ran out of money after weak repeat use, thin margin, and door-staff friction

Before you build

Why it matters

A real customer annoyance does not become a strong business unless venues, staff, users, and transaction economics all work repeatedly.

Primary check

Test redemption at the door, repeat purchase rate, and margin per transaction before building a payment app around a small offline workflow.

Checklist

  • Can you run a full night with manual redemption before building?
  • Can you prove more than one purchase per user?
  • Can participating venues explain their own reason to support the product?
  • Can the margin survive realistic acquisition cost?
  • Will operators accept the workflow during peak hours?
  • How many repeat transactions does each user need to break even?
  • Who pays processing fees and discounts?
  • What happens when staff refuse or forget the redemption process?

Relevant if

  • You are building payments around a small offline transaction.
  • Your product needs operators or staff to change an existing workflow.
  • Your revenue depends on repeat use and small transaction margins.

Less relevant if

  • Your product has no offline redemption or operator step.
  • You already have signed venue commitments and proven repeat transaction data.

Pre-build tests

  • Run a manual pilot with 1 or 2 venues and no custom app.
  • Track successful redemptions, failed redemptions, and repeat purchases.
  • Calculate contribution margin after fees, discounts, and acquisition cost.

Transferable lessons

  • Test redemption with real operators before custom app development.
  • Model processing fees and acquisition cost at the smallest transaction size.
  • Treat repeat purchase rate as a core product requirement.
  • Do not assume user convenience is enough for venues to change behavior.

If you build this today

Start with two bars, a manual redemption process, and a spreadsheet-level margin model before paying for a custom app.