Inside Cypress’s Playbook for Launching Usage-Based Pricing
Usage-based pricing is having a moment.
When you look at all the benefits of adopting usage-based pricing, it’s easy to see why. It coincides with achieving faster revenue growth at scale, building a truly customer-centric culture, and enabling a land-and-expand business model.
Still, ditching subscription-based pricing is easier said than done. Only one public SaaS company, New Relic, has fundamentally shifted towards a consumption model in the spotlight. The complexities are analogous to making the leap from on-prem to SaaS; it requires changes in go-to-market strategy, financial planning, sales processes, compensation models, and much more.
Usage-based pricing isn’t one-size-fits-all, either. Aspiring usage-based companies must select a value metric that works best for their customers and their product, as well as a pricing structure that minimizes friction in the customer journey.
With all this potential risk and complexity, is the juice really worth the squeeze?
That was a big question for the team at Cypress earlier this year as they pondered replacing their seat-based pricing model with a consumption-based one. The stakes were high—Cypress had recently raised a $40M Series B, and they have a passionate user community stemming from the company’s open-source roots.
I spoke with Mohammed Coovadia, VP of Customer Success and Sales, about what sparked the transition, how Cypress explored different pricing options, and what led them to a final decision.
As a front-end open-source testing tool, Cypress solves problems that get in the way of building modern applications. It’s easy to quantify the product’s value—GoDaddy’s GoCentral team, for example, noted a 70% increase in productivity. But GoDaddy notes that the real value can be derived from having confidence in the quality of your code.
Their original pricing model was primarily seat-based but included a usage component that set a pre-commitment for the number of test results per month.
This seemed like the perfect way to price the product. But as time went on and the team listened to real-time customer feedback, they learned that use cases didn’t line up with their initial assumptions. Most notably, testing was becoming more collaborative at companies.
“That feedback told us our pricing model was prohibitive not in terms of cost—we have a low entry price—but in terms of successful deployment and usage,” Mohammed explained.
Customers who ran very few tests ended up with unused capacity, which made them feel like they were overpaying. Customers who were growing rapidly and spinning up lots of new projects were constantly hitting usage limits, which slowed them down.
Both scenarios put the customer in the difficult position of having to choose which team members could participate in Cypress, write tests, review tests, and access results.
“Because our pricing kept our product from fitting naturally into their workflows, customers had to contort themselves to work with us. Forcing our customers to make trade-offs between their testing strategy and our pricing mechanics was the last thing we wanted. Our goal was to be a catalyst within their workflows, not a barrier,” Mohammed said.
As a product-led company, Cypress uses feedback as their primary decision-driver. So hearing that customers felt nickel-and-dimed snapped them into action. To land on the right pricing model, the team went through a four-step process:
1. Prioritization and discovery [1-2 months]
Cypress took an all-hands-on-deck approach and prioritized this initiative as a highly collaborative project shared between three functional teams: Product, Go-to-Market, and Finance. For additional support, they called on their investors—including OpenView—to help them recognize relevant patterns and opportunities. The team continued gathering feedback from customers and prospects, too.
In this first phase, Cypress solicited input about what was working well and areas to improve the current pricing. The team also used this time to explore a broad range of potential pricing models before honing in on a narrower set of ideas to bring into the research phase.
2. Research [2 months]
As an open-source software company with millions of users, Cypress needed to ensure any potential roadblocks were unearthed before deciding on a new pricing model. The research process was purposefully wide-ranging, spanning customer interviews, surveys, product usage analysis, and competitor studies.
- Internal signals: Investigated user provisioning and user activity behavior under the current user-based pricing model, which the team hypothesized was limiting adoption.
- Product behavior: Analyzed product usage over time across customers, including a mix of different usage metrics.
- Qualitative interviews: Interviewed 20+ existing customers and prospects to discover customer pain points with the existing pricing.
- Online survey: Surveyed 600+ customers and prospects to get a broader quantitative perspective.
- Competitive studies: Explored pricing models and recent pricing changes among other popular DevOps tools that customers used.
3. Testing and iterating [1-2 months]
The research results validated two potential value metrics for Cypress’s pricing. The challenge: there wasn’t one clear winner and both metrics had their drawbacks.
Cypress had to go deeper on both metrics. They iterated internally on them, mapped the data against their product and feature-set roadmaps, and looked at how each option would impact their go-to-market.
- “What if” tool: Built a tool that allowed the team to see what would happen under different pricing scenarios. That allowed Cypress to calibrate price metrics and price points based on real-world behavior.
- “Winner / loser” analysis: Visualized which customers would be most impacted by the changes including both “winners” (who would save money) and “losers” (who would see their bill increase)
- Qualitative discussion: The team facilitated a qualitative discussion around user experience and buying behaviors based on the two value metrics. It was a lot to unpack, but the team now had the perspective to guide and shape the conversation in a really productive way.
4. Decision [1 month]
After completing roughly five months of intensive pricing due diligence, it was time for a final decision. “There’s always the fear that you’ll make a bad call, that your choice will be punitive to some segment of your customer base or fail to deliver the expected outcomes,” Mohammed said. “But, eventually you have to take a little bit of a leap of faith, put it out there, and commit to the change.”
To move quickly, they didn’t view this step as a gate to getting ready for the launch. There were a number of activities that could move forward without having the final pricing ready: the new pricing page design, new messaging, and the plan for existing customers.
Cypress’s new pricing model
Cypress’s new pricing is a consumption-based model that scales most effectively with customers and their use cases. There are four tiers that cater to four distinct types of Cypress users. Each tier goes above and beyond Cypress’s free open source Test Runner product, which did not change as part of the pricing exercise.
- Free: For individuals and small teams who need only small numbers of views and tests
- Team: For slightly larger teams who want to be able to dial in the number of tests they need, and who can benefit from premium features like flake detection, JIRA support, and email support
- Business: For larger teams of up to 40 users who need advanced features like Smart Orchestration, Flake Management, GitHub integration, etc.
- Enterprise: For teams that need unlimited users along with bespoke features and services
With Cypress’s new pricing, the starting price of a paid plan was reduced from $100/month to $75/month to make it more affordable for those just starting out. That plan now includes double the number of users—from 5 to 10—to allow customers to open up access to their team.
Customers who start to exceed their included usage don’t need to worry about having to decide whether to upgrade to the next tier or have their usage throttled. Instead they can now pay for their exact usage starting at $6 per 1,000 test results. This means that customers will no longer have to worry about upfront guesswork or feeling like they’ve overpaid.
Cypress also launched two new plans for customers who are ready to deploy Cypress across their organization, Business and Enterprise. Both plans include access to features that organizations were requesting, such as single sign-on, premium support, and complex integrations, but that weren’t required by smaller customers. Cypress’s Enterprise plan also comes with unlimited users—a first for the company—so that larger organizations can open up the product to their entire engineering team.
The TL;DR: Cypress’s new pricing now facilitates land-and-expand. It’s easier than ever for customers to get started, scale their product adoption, and then (eventually) deploy enterprise-wide.
The Cypress team is closely monitoring the full impact of the pricing changes. But the early results look quite promising. First and foremost, existing customers have been proactively raising their hands to upgrade into Cypress’ new Enterprise plan, citing unlimited users as a strong catalyst to expansion.
A fear with consumption-based pricing is that it could throttle product usage since customers feel the marginal cost of consumption. That has not been the case so far at Cypress.
Given the consumption-based success stories of similar open-source software products like Elastic and MongoDB, Cypress will be one to watch.
Thinking about changing your pricing model?
- Ask for customer feedback about your pricing, not just your product. This feedback helps to create urgency around making a change and can unearth new ideas you might not have considered.
- Make sure the pricing initiative is an OKR-level priority. Doing it right requires a significant lift from multiple teams—even if you are leveraging a third party.
- Use pricing to reduce friction in how customers adopt your product. Make it easy for customers to get started, grow, and ultimately deploy at scale.
- Don’t be afraid of (healthy) debates. Pricing is one of the most cross-functional topics in an organization and so it’s only natural for your team to have different viewpoints. Take the time to align around a shared set of data points and then discuss the pros/cons of each pricing option as a group.
- Go for it. At the end of the day, there will always be some uncertainty, but you still need to make a decision rather than letting analysis-paralysis get the best of you. The good news: pricing changes tend to have a substantially positive impact on growth.
More usage-based pricing resources
We know a lot of folks are considering the switch, so we’ve curated a list of some of our favorite articles and guides.