Pricing Mistake
The proposal he sent, the price he wishes he'd charged, the lesson he keeps.
A pricing mistake can look like a bad number when the deeper problem is a bad pricing model.
In short
- • A pricing mistake can look like a bad number when the deeper problem is a bad pricing model.
- • Ryan Wang, co-founder and CEO of Assembled, described an early SaaS pricing problem in which the company's usage-based model had no minimum. During the pandemic, customers could reduce usage to zero without technically leaving, so revenue fell sharply.
- • In an interview summarized by SaaS Club, Wang described the period as eight months before the company earned its first dollar and explained how the team eventually added pricing minimums and changed how it worked with customers.
Pricing Mistake
A pricing mistake can look like a bad number when the deeper problem is a bad pricing model.
Ryan Wang, co-founder and CEO of Assembled, described an early SaaS pricing problem in which the company's usage-based model had no minimum. During the pandemic, customers could reduce usage to zero without technically leaving, so revenue fell sharply.
In an interview summarized by SaaS Club, Wang described the period as eight months before the company earned its first dollar and explained how the team eventually added pricing minimums and changed how it worked with customers.
The story is useful because the mistake was not simply "the price was too low." The pricing mechanism interacted with customer behavior.
What the pricing model was doing
A price has more than a number.
It also defines:
- what customers pay for;
- how payment changes with usage;
- where a minimum commitment begins;
- who carries demand risk;
- what happens when usage falls;
- which customer behaviors the model rewards.
A usage-based model can align payment with consumption. But without a floor or other protection, revenue can fall faster than customer count when usage collapses.
The decision Wang's story raises
Ask:
What happens to our revenue if the customer's usage falls by half?
Then ask:
- Does our delivery cost fall too?
- Does support cost remain?
- Is there a minimum commitment?
- Are we pricing the value or merely the activity?
- Can the customer understand the relationship between price and outcome?
These questions matter more than copying Assembled's exact pricing structure.
The correction
According to the published interview account, Assembled added pricing minimums and focused more closely on customers who were getting value. The company also learned that founder-led onboarding and custom work could work at a small customer count but become difficult to scale.
That creates a broader pricing lesson:
Pricing, onboarding and delivery capacity have to fit together.
A price that looks attractive in a spreadsheet can become unsustainable when every new customer creates expensive manual work.
A pricing-mistake audit
Write down:
Price metric: [What the customer pays for]
Minimum: [Lowest contracted revenue]
Variable component: [What changes with usage]
Delivery cost: [Direct cost]
Support burden: [Expected support]
Customer value: [What the customer is actually buying]
Failure case: [What happens when usage or demand falls]
Review trigger: [When pricing should be revisited]
The goal is not to find a universally correct price. It is to make the economics visible.
What the story does not prove
Assembled's experience does not prove that every SaaS company needs a minimum, nor that usage-based pricing is wrong.
The transferable lesson is narrower: stress-test the behavior your pricing model creates before the market stresses it for you.
Sources and methodology
- SaaS Club interview/episode with Ryan Wang of Assembled, documenting the company's early pricing experience and subsequent changes.
- The operational framework is SOE synthesis and is not presented as a claim made by Wang.
Editorial framing
This page is presented as an illustrative founder story rather than a documented biography or verified case study. The narrative is useful for the decision pattern it exposes; readers should not treat unnamed events, outcomes or dialogue as independently verified facts.
What to carry into practice
Identify the specific decision, the evidence available at the time, the trade-off the founder accepted, the result that was actually observed, and what would have changed the decision. Separate what happened in the story from the lesson SOE is synthesizing from it.
Evidence boundary
Where a story makes a factual claim about a company, market or research finding, it should be supported by a named source before being treated as evidence. This page does not use an unattributed statistic as proof.
Evidence note
This is a documented case study. The source records attached to this article identify the public material used for the account. The lesson is a synthesis from those sources, not a claim that the same intervention will produce the same result elsewhere.
Take it into your work
Do something with what you just read.
Save it for later, mark the passage that matters, or open your SOE workspace and keep thinking.
Takeaways
What to carry forward
- → Assembled's experience does not prove that every SaaS company needs a minimum, nor that usage-based pricing is wrong.
- → The transferable lesson is narrower: **stress-test the behavior your pricing model creates before the market stresses it for you.**
- → - SaaS Club interview/episode with Ryan Wang of Assembled, documenting the company's early pricing experience and subsequent changes. - The operational framework is SOE synthesis and is not presented as a claim made by Wang.
- SaaS Club interview/episode with Ryan Wang of Assembled, documenting the company's early pricing experience and subsequent changes. - The operational framework is SOE synthesis and is not presented as a claim made by Wang.