
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.
A buyer evaluating AI software now faces a problem that looked simpler in the seat-based SaaS era: the headline price often says far less than the eventual bill. A $20 monthly plan may include only an unspecified amount of agent work. A “contact sales” page may conceal not only the rate, but also the unit being sold, the required services, and the minimum commitment. Even a published price can become misleading when the vendor does not state the overage rule.
That gap matters because agentic products shift both value and cost. A coding assistant may help a developer move faster but still require review. A customer-service agent may resolve an issue without human help, creating a measurable outcome but also requiring deep integration with CRM, billing, and order systems. Treating both products as ordinary subscriptions produces bad buying decisions.
Monetizely’s position is clear: open pricing is the better buy for most B2B software and AI-agent purchases because it lets buyers test fit, forecast spend, and compare alternatives before entering a sales process. Hidden pricing earns its place only when the vendor is selling a genuinely customized, high-autonomy deployment with a clear output meter and material implementation work.
Open pricing does not mean every buyer receives the same price. Enterprise discounts, volume commitments, and custom security terms are normal. The threshold is simpler: a buyer should be able to determine the starting commitment, the billing unit, what is included, and what causes spend to rise before taking a sales call.
Cursor provides the clearest version of that model among the products reviewed. As of September 7, 2026, its public plan ladder runs from free Hobby to $20 per month for Pro, $60 for Pro+, $200 for Ultra, and $40 per user per month for Teams Standard. Cursor also discloses that agent usage can be billed at model-list prices after included usage is consumed. A developer can therefore estimate both the recurring subscription and the main source of variable spend.
Devin is more transparent than a sales-led enterprise product, but less transparent than Cursor on the total bill. Its public page lists Free, $20-per-month Pro, $200-per-month Max, and Teams at an $80 monthly platform fee plus $40 per full developer seat. Yet the included quotas refresh daily and weekly without a published conversion into a stable dollar or task allowance. Buyers know the access price but cannot know, from the page alone, how much autonomous work their team can expect before purchasing extra usage at API pricing.
11x takes a useful middle position. Alice’s Growth plan states a starting price of $3,750 per month, billed annually, for up to five end users and 2,000 new prospects per month. The vendor also states that it charges per lead rather than per send, bundles deliverability infrastructure and onboarding, and custom-quotes Pro and Enterprise. That gives a growth-stage buyer a usable starting point, even when a larger deployment requires negotiation.
Harvey and Sierra sit on the other side of the line. Harvey states that pricing is custom based on team size, deployment scope, and product surfaces used. Sierra promotes payment for outcomes rather than tokens, but does not publish a public rate card for those outcomes. Both approaches require a buyer to enter a sales process before learning the financial commitment.
Exhibit 1: The market has three distinct levels of price visibility
| Product | Public pricing structure as of September 7, 2026 | Target buyer | Packaging approach | Primary pricing metric | Transparency assessment |
|---|---|---|---|---|---|
| Cursor | Free; Pro $20/month; Pro+ $60/month; Ultra $200/month; Teams Standard $40/user/month; Enterprise custom | Individual developers, teams, enterprise engineering | Clear tier ladder from individual to enterprise controls | Active user subscription, with included usage and on-demand model usage | High - plans, rates, and usage mechanics are public |
| Devin | Free; Pro $20/month; Max $200/month; Teams $80/month plus $40/full developer seat; Enterprise custom | Developers and engineering teams seeking autonomous coding work | Individual, team, and enterprise plans | Subscription plus changing quota and API-priced extra usage; enterprise may use ACUs | Medium - access price is public, but usable capacity is hard to forecast |
| 11x Alice | Growth starts at $3,750/month billed annually; Pro and Enterprise custom | RevOps and outbound sales teams | Growth, Pro, Enterprise | New prospects per month, not sends | Medium-high - entry offer and meter are public; larger packages are quote-led |
| Harvey | Custom quote based on team size, deployment scope, and product surfaces | Law firms and in-house legal teams | Custom enterprise deployment | Contracted user access and product scope | Low - price, minimum, and package boundaries are unavailable before evaluation |
| Sierra | Custom enterprise sale; no public rate card | Large enterprises automating customer experience | Custom agent deployment | Outcomes, such as completed customer resolutions | Low on price, high on meter logic - the model is clear, but the economic commitment is not |
The table points to a central distinction: a vendor can keep enterprise flexibility without making the buyer guess how the commercial model works.
Many price pages disclose enough to attract a buyer but not enough to support a budget. The practical test is whether a finance leader can answer four questions without a sales representative: What is the minimum annual spend? What exactly counts against the meter? What is included in that spend? What happens when usage exceeds the plan?
Cursor answers three of the four well. The subscription prices are explicit, individual and team plans are visible, and its documentation explains that model selection changes usage consumption. The remaining burden is estimating usage, which is unavoidable when a customer can select different models with different costs. Cursor reduces that burden by publishing consumption and rate mechanics rather than hiding them behind a generic “fair use” statement.
Devin answers the first question but leaves the second unresolved. Its page says paid plans have daily and weekly allowances and that cost per message changes with model, task size, complexity, and reasoning. Those facts are candid, but they do not permit a buyer to translate a normal backlog of bug fixes, test-writing, or refactoring into likely monthly spend.
11x shows why consistency matters as much as disclosure. Its Growth card states “starting at $3,750 / mo” billed annually, while its FAQ says the Growth plan starts at $36,000 per year. Those figures imply annual commitments of $45,000 and $36,000, respectively. Until the vendor reconciles the two numbers in writing, a buyer should treat the entry commitment as unconfirmed.
Exhibit 2: A buyer can score pricing transparency before evaluating product quality
| Question a buyer must answer | Cursor | Devin | 11x Alice | Harvey | Sierra |
|---|---|---|---|---|---|
| Is the entry price published? | Yes | Yes | Yes | No | No |
| Is the billing unit named? | Yes - user and usage | Partly - quota and usage | Yes - prospect | Partly - team and scope | Yes - outcome |
| Is included capacity quantified? | Partly - usage pools vary by plan and model | No - quota is not expressed as stable task capacity | Yes - 2,000 prospects/month on Growth | No | No |
| Is overage or expansion logic public? | Yes - on-demand usage | Partly - API-priced extra usage | Partly - larger tiers are custom | No | No |
| Is the minimum annual commitment clear? | Usually | Partly | Not fully, given conflicting public figures | No | No |
| Overall buyer score, out of 5 | 4.0 | 2.5 | 3.0 | 1.0 | 1.5 |
A published price becomes decision-grade only when it exposes the rules that turn adoption into spend.
Monetizely’s 5-Step Pricing Framework explains why transparent pricing is not simply a website choice. The five steps are Goals and Segmentation, Packaging, Choosing the Right Pricing Metric, Finding the Right Price Points, and Operationalizing Agentic AI Pricing. The order matters. A company first decides which customers it serves and what it needs pricing to achieve. It then builds packages around those customer groups, selects the unit it will bill for, sets rates, and finally makes billing, product controls, invoices, and reporting work in practice. The discussion in Monetizing Agentic AI develops this sequence because agent pricing breaks when teams start with a number and work backward.
Cursor demonstrates the sequence in action. Its individual plans serve developers who want AI inside their editor. Teams add centralized billing, administration, and usage controls. Enterprise adds pooled usage, invoice billing, SCIM, audit logs, and more advanced access controls. The packages do not withhold the core coding job from lower tiers. Instead, they add the management features that larger organizations need.
That design makes open pricing possible. The buyer groups are legible, the package boundaries are legible, and the main meter is legible. Cursor still needs a usage layer because frontier-model costs vary, but that layer sits on top of a clear base offer.
Hidden pricing often signals that one of the earlier decisions remains unresolved. A vendor may be selling to too many distinct customer types through one sales motion. Or it may be mixing software, implementation, support, model usage, and custom integrations into an offer that has no stable boundary. In those cases, hiding the price does not solve complexity. It transfers the work of discovering complexity to the buyer.
AI pricing cannot be assessed only through price-page design. The underlying product changes the right meter. The Agentic Monetization Spectrum, or AMS, evaluates an agent on three dimensions: zero-human ability, operational domain, and output/cost ratio. Zero-human ability asks how much human work remains. Operational domain asks whether the product handles a task, a full workflow, or work across functions. Output/cost ratio asks whether the customer value rises roughly with compute cost or far faster than it. As the scores rise, pricing should move away from a simple seat and toward measurable output or outcome.
The spectrum supports open pricing for most lower-autonomy products, while explaining why Sierra can reasonably keep a bespoke commercial model. Cursor assists a developer who remains responsible for judgment and review. Sierra’s agents can work across customer-service channels and take action inside enterprise systems. One product is still anchored to a person; the other can be anchored to a completed business result.
Exhibit 3: AMS shows which products can support transparent seat pricing and which need an output meter
| Product | Zero-human ability | Operational domain | Output/cost ratio | Numeric score* | Pricing implication |
|---|---|---|---|---|---|
| Cursor | Medium | Medium | Inflecting | 6/9 | Seat-led pricing remains credible, with usage controls for costly model work |
| Devin | Large | Medium | Inflecting | 7/9 | Usage or accepted-work meter should carry more weight than seats |
| Harvey | Medium | Large | Exponential | 8/9 | Seat pricing fits legal buying habits, but heavy legal workflows warrant a visible usage or matter-based layer |
| 11x Alice | Large | Medium | Inflecting | 7/9 | Prospect volume is a better primary meter than flat access alone |
| Sierra | Large | Large | Exponential | 9/9 | Outcome pricing is appropriate, with a resolution or other business outcome as the primary meter |
*Small/linear = 1, medium/inflecting = 2, large/exponential = 3. Scores reflect the product positions set out in Monetizely’s AMS discussion.
The implication is not that every high-scoring agent should hide its rates. Sierra’s outcome model is well matched to its product, but a buyer still needs to know what qualifies as a resolution, which outcomes are billable, how disputed outcomes are handled, and the effective rate at different volumes.
Agentic AI creates a valid commercial problem: a vendor can lose money when a heavy user consumes costly models under a low fixed subscription. The answer is not hidden pricing. The answer is a stated primary meter paired with a clear variable-use rule.
Cursor does this best in the comparison. The primary meter is the user. That tracks the buying habit of development teams and gives a predictable recurring base. Included usage and on-demand pricing protect the vendor when a user runs expensive models or long-running agents. A company can set spending limits and monitor consumption rather than discovering a surprise true-up at renewal.
Devin takes a similar direction but with less buyer control. Its $20 Pro plan and $200 Max plan expose the access cost, while paid users may purchase extra usage at API pricing. The missing element is a published translation from the included quota to common workloads. A buyer does not need a guarantee that every bug fix costs the same. They do need a benchmark such as “typical small bug fix,” “test suite addition,” or “medium refactor,” with a range of expected usage.
Exhibit 4: Public recurring cost is only the floor when usage is variable
| Deployment scenario | Known recurring floor | What remains variable or unknown | Procurement read |
|---|---|---|---|
| 10 developers on Cursor Teams Standard | $4,800/year before usage overages | Model-routing and on-demand usage | Budgetable if the team sets usage limits |
| 10 full developer seats on Devin Teams | $5,760/year before extra usage | Daily and weekly quota capacity; API-priced extra usage | Pilot required before broad rollout |
| 11x Alice Growth | Public page implies $45,000/year from $3,750/month, but FAQ says $36,000/year | Which published annual minimum governs | Do not approve until the contract states the annual base |
| Harvey deployment | Not publicly disclosed | Seats, modules, deployment scope, and term | Require a full commercial schedule before proof of value |
| Sierra deployment | Not publicly disclosed | Outcome definition, rate, minimum, integrations, and volume commitment | Require a rate card for all billable outcomes before launch |
The practical standard is straightforward: variable pricing is acceptable when the buyer can cap, observe, and forecast it.
Harvey has a defensible reason to sell through a custom process. Its legal platform spans research, drafting, document review, workflow agents, shared workspaces, and integrations for law firms and in-house teams. The vendor says its pricing changes with team size, deployment scope, and product surfaces. A global firm deploying practice-specific workflows across thousands of matters is not buying the same package as a 15-lawyer specialty firm.
Sierra’s case is stronger on the pricing metric. Its agents operate across channels and can pursue customer-service outcomes over extended interactions. Sierra states that customers pay for results rather than tokens. For a large enterprise connecting the agent to customer data, order systems, payments, and service workflows, a custom deployment may be unavoidable.
Yet neither case justifies commercial ambiguity. A hidden rate card can remain private while still being complete. Before signature, the vendor should provide a schedule that states:
For Sierra, the primary meter should remain the successful resolution. A fixed annual platform fee can support implementation and platform access, but it must be explicit and secondary to the resolution meter. Charging primarily by tokens would force the customer to absorb model cost without preserving the value promise.
The better buy is not always the lowest entry price. It is the offer that lets the buyer connect spend to the job being done before making a commitment. Cursor is therefore the strongest purchasing model for developer productivity. Devin is viable for autonomous coding pilots, but only with a hard spend limit and evidence from the buyer’s own codebase. Harvey and Sierra can justify a sales-led process for complex enterprise work, but they should pass a far higher disclosure bar before procurement approves a rollout.
Exhibit 5: Buyer fit follows the transparency threshold
| Buyer profile | Best-fit product or commercial approach | Why it fits Monetizely’s position | Non-negotiable buying condition |
|---|---|---|---|
| Individual developer or small engineering team seeking coding productivity | Cursor Pro or Teams | Published plans map cleanly to individual and team needs | Set a monthly usage ceiling before enabling on-demand spend |
| Engineering leader testing autonomous work on defined tickets | Devin Pro, Max, or Teams pilot | Public access price supports a controlled trial, but total capacity remains uncertain | Measure dollars and reviewer time per accepted pull request |
| Growth-stage RevOps team with a known prospecting volume | 11x Alice Growth | Prospect volume is visible and the initial package is published | Resolve the $36,000 versus $45,000 annual-price conflict in the order form |
| Large law firm or enterprise legal department with specialized workflows | Harvey custom deployment | The breadth of legal workflows can justify custom scope | Obtain itemized pricing by users, modules, services, and renewal terms |
| Large enterprise automating customer-service work across systems and channels | Sierra custom deployment | High autonomy and broad scope justify outcome-led pricing | Contract on a precise resolution definition and a full rate schedule |
The pattern is consistent. Open pricing wins where the product is repeatable, the buyer can self-qualify, and the unit of value is familiar. Hidden pricing is acceptable only when repeatability breaks down before the deal is sold, not when a vendor simply prefers negotiation leverage.
Set a company-wide rule that every offer has a published primary meter. Even enterprise products should explain whether buyers pay for users, prospects, resolutions, transactions, or another unit before the first sales meeting.
Build a price page around annual commitment, not monthly headlines. Buyers need to see the minimum term, required platform fees, included services, and the conditions that increase spend.
Require every agent vendor to provide a workload-based forecast. Ask for three customer-relevant scenarios - light, expected, and heavy use - tied to the buyer’s actual task types or interaction volumes.
Use pilot evidence to choose the meter before negotiating a long-term contract. For coding agents, track accepted pull requests and reviewer time. For sales agents, track qualified pipeline. For service agents, track verified resolutions and escalations.
Reserve custom quoting for deployments with real implementation variation. If most customers receive the same product, same security package, and same meter, publish the price. Sales assistance is not a reason to hide it.

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