Pricing Engineered is a series of expert interviews, featuring CTOs and tech leads from the world’s most forward-thinking companies who share their insights from building innovative solutions to maintaining their pricing models.
Patrick is the cofounder and CEO at Reclaim.ai, a smart calendar assistant to schedule tasks. He’s a 3x founder, 3x dad, former SVP at New Relic, and has previously been contributing to various open-source projects, such as WebWork/Struts, Selenium, and OpenSymphony.
A few months ago, he and his team built an entitlement infrastructure for Reclaim.ai to manage their pricing model and handle trials and subscriptions. In this episode, he’s giving us an exclusive look inside their system and how they’ve built it.
You can connect with Patrick on LinkedIn and Twitter.
Why did you decide to build your own entitlement infrastructure?
By the time we were planning to monetize our product, we didn’t find a solution that covered our needs. There are tools for billing, subscription management, metering, … But the market didn’t offer any solution to build and maintain the actual pricing model end-to-end.
We’ve decided to build on top of Stripe’s basic functionality and create our own infrastructure.
So, we’ve decided to build on top of Stripe’s basic functionality and create our own infrastructure.
Tell us about this infrastructure. What does it allow your team to do?
Our infrastructure is built to support the maintenance of our specific pricing model, a good-better-best structure, charged annually per seat. Capabilities include gating features, everything around trial support, customer portals, usage patterns, upgrade/downgrade flows, …
We’ve had to build a lot of things for this infrastructure and there are many different systems involved: We’re using Stripe for billing and for part of their self-service capabilities to let users update the number of their seats, see proration, etc.. Intercom, Airplane, behind-the-scenes utilities, retool dashboards, … We had to build the entire UI, the backend logic to look at assigned seats, our clawback function, …
Looking back, what were the key challenges you’ve faced?
We had several lifecycle and workflow related issues within this project.
For example, seats are a gated functionality in our pricing model. We had to build the entire logic behind inviting new team members who were not yet users of Reclaim.ai; flows if they accept or decline the invitation; the behavior of the counter inside the customer portal; …
Also, individuals can join a paid account as a trial. That allows the new user to experience all capabilities of the product without taking down a seat from the paid account. That was very hard to define for our infrastructure. And then, after the trial ends, they lose some of the functionalities. So, certain buttons have to be disabled. We’ve needed to add notifications, gate access to different features, …
We’ve wanted to create a lot of automation behind users losing functionality. So, we’ve built a prediction addition that shows us a breakdown of top features for users in trial and sends this data to our CMS to evaluate which plan the user should continue with once their trial is over.
Another challenge was our referral program, where users get credits for inviting others to the product. If that user was a paying customer, but then hits the milestone for a free month and wants to redeem their credits, do we put the subscription on pause? Eventually, we decided not to make this flow self-served and added a “Contact Us” button
When we started with the infrastructure, we had two years of free users — around 70K. Once we moved to paid subscriptions, we had to disable those users. By the way, this resulted in many subscriptions. People often don’t pay, until they lose functionality. We gave those free users a 24h grace period. That was also something we had to build.
How big was the team of developers who built the solution?
Out of the 13 people in our company, 3 worked on this infrastructure — 1 frontend developer, 1 backend developer, and me.
From the kickoff, how long did it take to push the solution to production?
Well, we had a first cut of the platform in about 3 weeks.
By then, I thought “Oh yeah, we’re almost done!”. And I’d say I’m quite seasoned, so I knew probably about 50% of what we needed, right from the start.
It took 3–4 more months of full-time efforts by several engineers to get to what we have today. Both, for bug fixing and discovery.
All the trialing setup was the most difficult part. We found funny little glitches, where part of the UI was not gated, so people could still turn on a feature they weren’t supposed to.
All the trialing setup was the most difficult part. We found funny little glitches, where part of the UI was not gated, so people could still turn on a feature they weren’t supposed to.
We only discovered that months later.
Since going live, how much effort are you investing in maintaining your solution?
For our current pricing model, this infrastructure serves us well.
However, there’s tweaking a model and there’s changing a model.
I believe it’s healthy for a business to change their pricing fairly dramatically every 3–4 years. Many businesses today are way too slow with that.
I believe it’s healthy for a business to change their pricing fairly dramatically every 3–4 years. Many businesses today are way too slow with that.
So, for the next few years, we can add entitlements for new features and tweak our plans with our existing infrastructure. Once we have to completely change this model, that will be a different story.
What do you suggest to developers who think of building a pricing infrastructure?
Modeling and language!
Developers don’t speak pricing language — entitlements, recognized revenue, subscriptions, metered vs tiered models, add-ons, …
When you get started, there’s all this lingo that can be really intimidating. We don’t know all this stuff. So, what ends up happening is that many things are not thoughtfully crafted together and you find out only when you’re in the middle of it. Things like “How do we want to bundle up the entitlements of features?” are being figured out on the fly. It’s very inefficient to just figure it out just in time when you bump into the problems.
When you’re thinking of building something yourself, I’d encourage you to start by stepping back and trying to document the modeling and the language that makes up your billing platform.
And that’s hard. You don’t know what you don’t know.
