Tiers
Tiers launched into SaaS pricing experiments and got early attention, then shut down when the founder found price testing too infrequent and hard to insert into teams' workflow.
View original storyProduct snapshot
What it was
Tiers was a SaaS pricing experiment tool for testing and managing price tiers.
Who it was for
Problem / value
It aimed to help teams test pricing changes more systematically instead of guessing from static price pages.
Core workflow
Teams configured pricing tiers, ran or planned price tests, and reviewed whether a pricing change improved conversion or revenue.
Core dependency
The workflow had to fit into billing, checkout, and pricing-page decisions that teams changed infrequently.
Product form
Competitors or alternatives
What happened
Summary
Tiers was built to help SaaS teams test and manage pricing tiers more systematically.
Outcome
The founder shut it down after concluding that price testing did not happen often enough and was hard to embed into SaaS company workflows.
Core risk
A valuable but rare workflow may not support a dedicated SaaS tool.
Shutdown reason
The public shutdown post points to low workflow frequency and adoption friction, not just product awareness.
Before you build
Why it matters
Pricing matters, but many SaaS teams change prices rarely, carefully, and inside existing billing or analytics workflows. A separate tool has to earn its place in that cadence.
Primary check
Prove pricing changes happen often enough, and that teams will adopt a separate workflow, before building pricing experiment software.
Checklist
- How often does the buyer run this workflow?
- What existing tool owns the workflow today?
- What would make the buyer add a separate product?
- Can the tool be embedded where the workflow already happens?
Relevant if
- You are building software for pricing, compliance, audits, migrations, or another rare workflow.
- Your product depends on teams adopting a separate tool for an occasional decision.
- Early attention comes from founders who agree the topic is important.
Less relevant if
- The workflow happens weekly or monthly for the same buyer.
- You are embedding inside an existing billing, checkout, or analytics system.
Pre-build tests
- Interview teams that changed pricing in the last 90 days.
- Manually help three teams run a pricing test and see whether they ask for software.
- Test an integration or template before building a full app.
Transferable lessons
- Measure workflow frequency before building a dedicated tool.
- Test adoption inside the buyer’s existing process.
- Do not confuse topic importance with recurring product usage.