
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Join companies like Zoom, DocuSign, and Twilio using our systematic pricing approach to increase revenue by 12-40% year-over-year.
The case for customer-built plans is easy to understand. A buyer asks for an extra integration, a different usage cap, a lighter support model, or a feature that sits in another tier. The sales team sees a deal at risk and wants room to assemble the exact offer needed to close it.
Agentic AI raises the pressure. A coding agent may need frontier-model access, cloud execution, audit logs, pooled usage, and controls for autonomous actions. A customer-service agent may require voice, CRM access, order-management workflows, and a definition of a successful resolution. An open menu seems like the respectful answer to that variety.
Yet letting customers build their own plan often moves complexity from the supplier to the buyer. Instead of deciding whether the product solves a job, the buyer must now decide which components solve it, which will be needed next year, and whether the final invoice will make sense. That slows purchase decisions, weakens willingness to pay, and gives sales teams too many ways to sell around the product.
Monetizely’s position is clear: most agentic SaaS companies should not let customers build their own plan. Prebuilt offers with a named primary metric are the better buy for individual users, functional teams, and most mid-market buyers; vendor-led custom design belongs only in enterprise deployments where the work itself is genuinely custom.
Monetizely’s 5-Step Pricing Framework starts with Goals and Segmentation, then moves through Packaging, Choosing the Right Pricing Metric, Finding the Right Price Points, and Operationalizing Agentic AI Pricing. The order matters. A company cannot rationally decide whether buyers should assemble components until it knows which customer groups it serves, what job each group is hiring the product to do, and what unit best tracks value. Rate setting comes fourth because a price is only defensible after the offer and meter are settled. The final step tests whether the company can actually measure use, apply entitlements, explain invoices, and manage exceptions. The fuller argument appears in Monetizing Agentic AI.
A customer-built plan reverses that sequence. It starts with components, then asks the buyer to discover the right package through negotiation. That approach can work when each deployment is a distinct operating project. It fails when the customer is mainly buying a repeatable product.
A useful plan should let a buyer answer three questions quickly:
A package that requires a solutions consultant to answer all three has not simplified buying. It has simply hidden complexity behind flexibility.
The current market offers a useful comparison because the leading agentic vendors have chosen sharply different commercial designs. Some put customers into clear tiers. Others price through a custom enterprise process. The relevant contrast is not “simple versus sophisticated.” It is whether the packaging matches a repeatable buyer job or asks every customer to invent a commercial arrangement.
Public pricing pages checked on September 3, 2026 show five distinct designs across coding, legal, customer experience, and sales automation. -
The pattern is instructive. Cursor, Devin, and 11x put most buyers on a visible path before a salesperson becomes involved. Harvey and Sierra reserve custom design for buyers purchasing broader, high-stakes deployments where integration, controls, and operating scope shape the product itself.
That distinction is the central one. A company should not give buyers a box of pricing parts merely because its product has many capabilities. It should give buyers a clear package unless the customer’s environment materially changes the work delivered.
The Agentic Monetization Spectrum, or AMS, helps separate two decisions that companies often blur together: how autonomous an agent is and how much freedom a buyer should have to assemble a plan. AMS evaluates an agent on three dimensions. Zero-human ability asks whether a human mainly performs the work, delegates and reviews it, or is largely removed from execution. Operational domain measures whether the agent handles a narrow task, an end-to-end workflow in one function, or work across several functions. Output/cost ratio compares the value of the output with the cost of producing it. As autonomy, domain breadth, and value relative to cost rise, pricing should move away from a human seat and toward an output or outcome. The spectrum does not argue for more package customization. It argues for a better meter.
The following read uses the AMS categories of Small, Medium, and Large for the first two dimensions, and Linear, Inflecting, and Exponential for the third.
The table clarifies why simplicity and outcome pricing are not opposites. Sierra can charge for resolutions while keeping the commercial promise clear: the customer buys a defined enterprise agent and pays against a measurable result. Cursor can charge per developer seat because the human developer still directs and reviews the work. Both approaches remove unnecessary choices from the buyer’s task.
Devin’s current design is especially useful. Its Teams offer distinguishes between full seats for regular users and flex seats for occasional users, while keeping a shared pool of usage credits for extra consumption. That is controlled flexibility. The customer selects a user type based on real behavior; the customer does not negotiate a bespoke combination of code review, cloud agents, administration, and security modules.
A common pricing mistake is to treat every buyer difference as a reason for a new package. Often the buyer’s underlying job is stable, while the governance, scale, and buying process differ. Cursor illustrates the point well: a solo developer needs the editor and agent; a team needs billing and administration; an enterprise also needs security, auditability, and controls. The core job remains writing and shipping better code.
The buyer-fit question should therefore begin with the work being delegated. A product choice follows from that question more reliably than a feature checklist does.
The implication is direct: prebuilt plans are not a refusal to segment. They are segmentation made visible. Buyers should see themselves in an offer before they enter a negotiation.
11x’s current Alice pricing shows why the distinction matters. Its Growth, Pro, and Enterprise offers separate first-time outbound users from teams expanding across markets and large organizations running broad programs. The company prices per lead rather than per send, which keeps the meter closer to useful work than raw email volume. The design is not perfect - a lead is still weaker than a qualified opportunity or booked meeting - but the customer is buying a recognizable operating model rather than assembling one.
Custom pricing is often defended with a familiar claim: “Enterprise customers are different.” Many are. The hard question is whether the difference changes the product delivered or simply reflects a salesperson’s desire to preserve negotiating room.
We recommend a custom plan only when all three conditions are present:
The following decision table turns that standard into an operating choice.
The table points to a demanding rule: custom is not an open menu. Custom is a supplier-led design process with a clear commercial anchor. Sierra may tailor the implementation, but the buyer should still understand what constitutes a resolution. Harvey may tailor a deployment, but the vendor should still define the user population, scope, service level, and governance model.
A modular price list does the opposite. It asks customers to make product-design decisions that the vendor has more information to make. The buyer may choose too little and fail to realize value, or choose too much and discover shelfware at renewal. Either outcome damages trust.
The strongest packaging designs make complexity real inside the product while keeping it manageable in the commercial offer. Cursor does not need to sell a separate code-context module, model-access module, team-billing module, and security module to every engineering organization. It can reserve controls and administration for the team and enterprise tiers because those capabilities matter most when the buyer’s organization becomes more complex.
That discipline protects value. A broad feature menu can create a race to the lowest acceptable configuration. Procurement removes modules to reduce price. Sales adds them back as concessions. Product teams lose a clean view of adoption because customers own unusual combinations. Finance inherits invoices that require manual explanation.
The effect is particularly dangerous in agentic AI, where model costs can rise with task depth, tool use, and autonomous execution. Cursor’s commercial terms explicitly accommodate subscription fees, usage fees, precommitted usage, and on-demand usage for enterprise customers. That complexity belongs in the supplier’s billing logic. Buyers need a clear plan, visibility into consumption, and known rules for additional use. They do not need to construct the pricing engine themselves.
Our view is that companies should place variation in only two places:
Everything else should be treated with suspicion. A feature should become a separately priced add-on only when it unlocks a distinct, valuable job for a distinct buyer group. “Some customers asked for it” is not enough.
The temptation to allow build-your-own plans usually starts as a sales exception. One strategic prospect wants a feature from the top plan and a price from the middle plan. Another asks for lower volume but more support. A third wants an enterprise control without the enterprise commitment.
A company that accepts each request may still close those deals. Over time, though, it stops having packages. It has a private collection of deal histories.
The better discipline is to make the offer architecture a strategic choice. Cursor’s public tiers signal who the product is for. Devin’s distinction between full and flex seats signals how teams should adopt it. 11x’s lead-based tiers signal that outbound scale, not email sends, drives expansion. Harvey and Sierra signal that their product is aimed at complex enterprise work where the vendor must help define the deployment.
Each design gives the market a clear answer. That clarity is not a cosmetic benefit. It determines whether sales can qualify quickly, whether buyers can compare options, whether finance can forecast spend, and whether product teams can improve a coherent offering.
Choose the customer group you will deliberately not serve with the current product. A clear exclusion protects the package from being stretched into a poor fit for every possible buyer.
Set a one-year commercial architecture commitment. Treat plan changes as product decisions, not deal-level concessions, and require executive approval for exceptions that create a new pricing pattern.
Measure package health by movement, not only by bookings. Track which plans buyers choose, which customers expand, which features drive upgrades, and where discounts repeatedly appear.
Give product management ownership of package boundaries. Sales should report where buyers fail to fit; product and pricing leaders should decide whether that evidence warrants a new offer.
Design the renewal story before launching the plan. A customer should know, at signature, what event will increase spend and what evidence will appear on the invoice when it does.

Join companies like Zoom, DocuSign, and Twilio using our systematic pricing approach to increase revenue by 12-40% year-over-year.