Scaling Monetisation with Seat-Based Pricing
From Chaos to Clarity: Rethinking Pricing at Appsmith
role
Senior Product Designer + Acting PM
engineers
2 Backend + 1 Frontend
timeline
Oct 2024 - Jan 2025
company
Appsmith (Platform Admin Pod)
tldr
Appsmith's strategic pivot to $15/user seat-based pricing has already delivered 40 paying customers and an initial $3,240 MRR by Feb '25.
This isn't just about instant riches; it's about unrivalled predictability for users and building a sustainable path to massive MRR growth through increased adoption. See how we turned pricing headaches into clear, measurable progress and a blueprint for long-term success!
Jump to —
Why Usage-Based Pricing Was Breaking Things
We used to price Appsmith based on monthly active users. It made sense at first. But as we grew, it got messy. Customers didn’t understand why their bill kept changing. Public app access made billing unpredictable. Admins couldn’t plan. We heard it clearly: "We want a pricing model that's easier to manage."
Bills spiked unexpectedly based on user activity.
Anonymous users accessing public apps added to the confusion.
Customers couldn’t forecast costs.
Internal teams spent time clarifying pricing, not delivering value.
Usage based pricing dashboard
The Ask: Make Pricing Simple, Predictable, and Scalable
We needed a pricing model that gave admins control
Gave admins control
Made billing predicable
Let customers manage growth without surprises
The Stakeholder Thesis
The platform-admin team already had thoughts. After a big stakeholder sync, I was pulled in to design the actual experience. They’d done the backend research, compared models across the industry, and landed on a direction: seat-based pricing.
First thread for the epic
Wearing the Acting PM Hat
There wasn’t a product manager fully dedicated to this track. So I stepped in.
I started by studying the internal proposal. Then went deeper — Slack threads with the backend team, Edge case explorations ("What if a user goes inactive mid-cycle?"), Role mapping: viewer, admin, guest.
Defined scope, clarified business logic, mapped user journeys, and drove alignment across design, dev, and revenue teams.
Writing the PRD That Everyone Could Rally Around
The PRD covered — Scope (Business Plan, monthly only), Succes metrics, Roles + seat assignment logic, Billing flows (purchase, edit, cancel), Edge cases (trial users, deactivation, Stripe proration), Design timeline
Private notion PRD
Centering Around Job Stories
When I am purchasing licenses for Appsmith, I want to use a predictable pricing model that allows me to forecast expenses for the year, so that I can confidently budget for the Appsmith license cost and avoid unexpected financial strain.
Parent job story
Private notion PRD
Mapping Scenarios and Untangling the Flow
I laid out — How-Might-We questions for sticky moments, and the existing usage based pricing flow
HMWs
Old Appsmith billing flow
Also determining the scenarios with some personas to understand how the final flow can be along with determining the difference between two IAs
Basic scenarios to deal with
Old IA vs New IA
How others are approaching it
Seat-based pricing isn’t new — but the way companies implement and communicate it makes all the difference.
We looked at how others do it:
Slack: Clear distinction between paid members and guests. Admins have complete visibility into seat usage and can manage roles from a single place.
Linear: Seat pricing with a self-serve flow that highlights predictability. Billing clearly tied to assigned users, with graceful flows for upgrades and removals.
Dovetail: Flexible admin interface where seat management is tightly coupled with team roles and usage insights. Elegant billing breakdown by team and feature access.
Notion: Allows bulk invites and auto-assignment of seats, but always prompts admins before adding paid seats — combining flexibility with cost control.
Sketch First, Ask Later
I created early sketches and flow to fit in — Simple counters for seats, Assign user modal, Inactive seat alerts. These gave us something to critique together before high-fidelity design.
Proposed new flow
New Appsmith billing flow with sketches
Claude as Copilot (llm based full stack platform)
Generated low-fi prototypes with Claude — Purchase flow with auto-selected users, Add/remove seat flows, Stripe proration preview logic, They helped in async reviews and quick iteration.
Loom video
Explaining whole flow with claude prototypes
Purchasing seats
Approach 1 - Select/Deselect users along with counter while purchasing - Check Claude for the ideation
Approach 2 - Only seat counter prefilled with no.of users and list of users visible - Check Claude for the ideation
Add/Remove more seats
Refined Solution for the Purchasing Seats & Billing
After the feedback on the slack threads and on the other figma files, we've reached the point to finalise the purchasing seats and billing flow.
Purchase seats
Loading state
Billing tab
No users across instance
Loom video
Design System Gap? Built It.
During high-fidelity design, I hit a blocker: we didn’t have a table component variation for seat management. So I designed one from scratch.
How other products use the table component
Here are the different variations we have tried and finalised the one that is suitable for the functionality of managing seats
Final table component
With table component - Refined solution for members
After the feedback on the slack threads and on the other figma files, we've reached the point to finalise the purchasing seats and billing flow.
Members tab
Seats full
Empty state
Invite members
Early Signals: Metrics, First Customer
We landed our first seat-based pricing customer on January 10th, 2025 — a moment that marked the beginning of predictable, scalable monetisation.
The impact was immediate: within three months, MRR crossed $6,900, showing steady month-over-month growth. Interestingly, revenue rose significantly even though the number of new customers remained steady, validating that seat-based pricing increased revenue per customer and simplified the upgrade path.
First paying customer
MRR
New customers vs Revenue
Website will be revised in actual code soon
@ Roop Krrish 2025