Tilt
Tilt was a social payments and crowdfunding app for group trips, parties, events, and projects. Its Airbnb acquisition shows how useful payment workflows can become features inside larger transaction platforms.
View original storyProduct snapshot
What it was
Tilt helped groups create campaigns, invite contributors, and collect money for shared plans.
Who it was for
Problem / value
It made group funding easier for trips, parties, events, and community projects.
Core workflow
An organizer created a campaign, invited contributors, collected payments, and funded a shared activity or project.
Core dependency
The standalone product depended on a recurring payment context, repeat organizer behavior, and a reason to use Tilt outside larger transaction platforms.
Product form
Pricing model
Public sources describe Tilt as a social payments and crowdfunding service but do not disclose take rate, fees, revenue at acquisition, gross margin, or customer acquisition cost.
Competitors or alternatives
What happened
Summary
Tilt moved from group crowdfunding toward broad social payments and was later acquired by Airbnb, suggesting the workflow may have been more valuable inside a larger transaction context.
Outcome
Tilt’s assets and team moved into Airbnb rather than proving a clearly documented long-term standalone consumer destination.
Core risk
Group payments lacked standalone recurring context.
Timeline
- Crowdtilt renamed to Tilt in 2014 as it looked beyond the crowdfunding niche.
- TechCrunch reported strong revenue and campaign growth at the time of the rebrand.
- TechCrunch reported Airbnb was in talks to acquire Tilt in January 2017.
- Airbnb finalized the Tilt acquisition in February 2017.
Before you build
Why it matters
Group payments can be useful across many situations, but broad usefulness does not automatically create a standalone habit. The stronger business may sit inside a platform that already owns the trip, event, purchase, or community transaction.
Primary check
Before building a broad group-payments product, prove one recurring transaction context where organizers return, contributors pay, and the workflow is valuable outside a larger marketplace.
Checklist
- What repeat context makes organizers come back?
- Who owns the demand before payment happens?
- Does the workflow work without a larger marketplace?
- What is the successful funding rate and repeat campaign rate?
- Would the product be stronger as a feature inside another platform?
- Pick one recurring payment context before broadening.
- Measure repeat organizers, not only campaign creation.
- Track contribution conversion and successful funding rate.
- Compare standalone usage with embedded marketplace usage.
- Know which larger platforms already own the transaction moment.
Relevant if
- You are building group payments, crowdfunding, event payments, creator contributions, marketplace checkout, or community funding tools.
- Your product is a payment workflow without owning the underlying demand context.
- You are expanding from one narrow use case into a broad payments category.
Less relevant if
- You already own the transaction context where payment happens repeatedly.
- Your product is embedded in a marketplace with clear demand and repeat behavior.
Pre-build tests
- Run one vertical campaign workflow manually before building broad payments.
- Track whether organizers create a second and third campaign.
- Test embedded payment collection inside an existing marketplace or event flow.
Transferable lessons
- Start from a frequent painful payment context, not a broad group-payments category.
- Measure repeat organizer behavior and successful funded campaigns, not only campaign starts.
- Payment features often work best where the surrounding marketplace owns demand.
- If larger platforms own the transaction context, expect feature absorption pressure.
- Choose one vertical where payment collection is urgent and repeated before broadening.