When we first started building Commet, we modeled our billing system like traditional e-commerce platforms. Products, prices, variants, tiers. The whole catalog approach that payment processors like Stripe use.
We spent three months building and we launched.
One week later, we knew something was wrong.
Every customer call felt harder than it should. Explaining how to set up a simple pricing page required walking through products, list prices, price variants, and subscription items. Founders would nod along, but you could see the confusion.
The insight was simple: SaaS companies don't sell products. They sell plans.
We made a decision: rebuild the core architecture. Two weeks of intense work later, we shipped a completely new model.
The Product-Based Approach
Our original architecture looked like this:
Product: "API Platform"
├── List Price: "Starter Plan" → $50/month, 10K calls
├── List Price: "Professional Plan" → $200/month, 100K calls
├── List Price: "Enterprise Plan" → $500/month, 1M calls
└── Price Variant: "Acme Corp" → 20% discountThis is how most billing platforms work. You create products, attach prices, create variants for custom deals, and wire everything together with subscriptions that reference multiple products.
For payment processors and marketplaces, this makes sense. But for SaaS? It created unnecessary complexity.
Every time a founder wanted to create a simple pricing page with three tiers, they had to think about products, list prices, price variants, and how they all connected. The mental model didn't match how they actually thought about their business.
How SaaS Companies Actually Sell
When you look at any SaaS pricing page, you don't see a product catalog. You see plans.
Notion doesn't sell "Document Storage" and "Team Collaboration" as separate products. They sell Free, Plus, Business, and Enterprise plans. Each bundling different capabilities.
Linear doesn't sell "Issue Tracking" with add-ons. They sell Starter, Pro, and Business plans that include everything.
Vercel doesn't make you pick between "Hosting" and "Edge Functions" products. They sell Hobby, Pro, and Enterprise plans with different limits.
Plans are the unit of sale. Features are what's included. Usage determines overages.
The Plan-First Model
We rebuilt Commet around this insight:
Plan "Pro" - $99/month
├── API Calls: 10,000 included, $0.01/extra
├── Team Members: 5 included, $25/extra
├── Custom Branding: enabled
└── Priority Support: enabled
Customer → Subscription → Plan → Automatic billingInstead of products referencing prices referencing variants, you have:
- Features: The capabilities you sell (boolean, metered, or seats)
- Plans: Packages that configure features with limits and prices
- Subscriptions: The contract between customer and plan
That's it. No catalog management. No price variant hierarchies. No wondering which product goes with which subscription item.
Why This Matters
1. It matches how founders think
When a founder says "I want a Pro plan at $99/month with 10K API calls included," they can create exactly that. The mental model in their head matches the data model in Commet.
No translation layer. No "first create a product, then a list price, then configure the subscription items."
2. Features drive the model
In the product-based model, usage metrics and seat types were awkward add-ons. You'd create a "product" for API calls, attach a usage metric, and hope everything wired up correctly.
In plan-first, features are the building blocks:
- Boolean features: Custom Branding, SSO, API Access
- Metered features: API Calls, Emails Sent, Storage Used
- Seat features: Team Members, Admin Users, Editor Seats
Each plan configures these features with specific limits and overage prices. The billing engine knows exactly what to charge because the model is explicit.
3. Plan Groups enable self-service
With products, upgrades and downgrades were complicated. Which products can upgrade to which? How do you handle prorations across multiple subscription items?
With Plan Groups, you define which plans can upgrade between each other. The Customer Portal handles the rest:
Plan Group "Main Pricing"
├── Starter ($29/month)
├── Pro ($99/month)
└── Business ($299/month)
Customer on Starter can self-upgrade to Pro or Business.
Prorations calculated automatically.The Rebuild
Once we saw the problem, we moved fast. In two weeks, we rearchitected the entire billing model:
- Migrated from products and price variants to plans and features
- Rebuilt the billing engine to handle the new model
- Ensured every pricing model still works (fixed, usage-based, tiered, seats)
- Updated the SDK and documentation
What We Learned
Building billing software taught us that the best architecture isn't the most flexible one. It's the one that matches your users' mental model.
Payment processors need product catalogs because their customers sell physical goods, digital downloads, and services. The flexibility is essential.
SaaS billing platforms need plan-first architecture because their customers sell subscriptions with features and usage. The simplicity is essential.
The hardest part wasn't the technical work. It was admitting, one week after launch, that we'd built the wrong abstraction. But that's the only way to build something people actually want to use.
If you're building a SaaS or AI product and want billing that matches how you actually think about pricing, check out our documentation or explore the platform overview.
We think you'll find that plan-first billing just makes sense.