Remodeling our pricing
You can see our new pricing model here.
One of the most challenging things for any company is to find a pricing model that works for all their customers and their balance sheet. We’ve tried a lot of different models over the last few years, and have always run into issues.
We realized mid-way through last year that to resolve these problems, we needed to learn a lot more about you (our users), what you valued in the product, and how you made decisions. We’re always trying to learn from our users, but a lot of the data we were getting was colored by the existing pricing on the website.
We had very few options to give ourselves a clean slate to start again from. This led us to make the difficult, and (somewhat) controversial decision to remove the public pricing from the website.
Without the existing expectations being set by having a public pricing model, we began to see a dramatic effect on both the quality, and quantity of conversations we were able to have with you all. It quickly became clear that we had a plethora of unique use cases, all with different pricing expectations.
What we learned
- You are overwhelmingly technical - we’re an API, so no surprises there.
- Almost 100% of you are however able to make purchasing decisions within your organisation with the majority of you being CTOs, VPs of Engineering, or Lead Developers.
- We expected the majority of our user base to be made up of startups, but it turns out that’s just not true at all - don’t get me wrong there are a lot of you, but the number of SMB and small-mid Enterprise customers lurking was a surprise to us all.
- We also have an equal distribution of retailers, services, and agencies using Moltin.
- None of you understood clearly what API request volumes you’d need, how to plan for it, or how much it would cost you or your own clients to use the platform.
- You love Flows and Events, with these being the most unique and important features outside of the core feature-set by far.
- Most of you agree that the documentation is good, but do think we can do better with it.
- You want to see more demos and reference applications.
- Above all, you overwhelmingly wanted clear, transparent pricing to make a return…
The most positive aspect of disabling pricing was the (literal) thousands of conversations we had with you all. Seeing the frustrations of people who want to pay, but were unable to get the pricing information that they needed to hand meant we opened up the door to many one-on-one conversations to understand your business requirements. We were able to learn a lot more about your motivations for using Moltin, some of the amazing projects you were wanting to go build, and how you value what we offer. Conversations we may not have had with a pricing page live that we didn’t truly believe in.
We spent a considerable amount of time last year doing what most companies do. Sitting around a table deciding whether our pricing model was going to favor a large number of small customers at an early stage of growth, or a smaller number of enterprise customers. But having now dug through the data, and seen that people are building projects for all sizes and scale has meant we know we have to have a pricing model to suit you all and not favor one over the other.
How we guided our decision
We started with a number of core-tenants to create a decision framework, we didn’t yet know what we wanted, but we certainly knew what we didn’t want to see as an end-product. An overview of what we were looking for was:
- It had to be simple - we didn’t want you to have to earn a PHD just to be able to figure out your monthly bill.
- It had to be scalable - to allow more of you to get started easily with low friction, but quickly scale with you as your company grew.
- We wanted to make it fair - if we got to a point where we were incentivizing you to work around the pricing structure, or avoid using functionality, we’d done something wrong.
What we’ve done
Over the past few months we’ve spent a lot of time working with a lot of you on testing models, trying various scaling mechanisms, and price points. The biggest overall change we’ve made is to move away from request volumes. You don’t like them, we don’t want to force them on you, so they’re out.
Revenue was the aspect of running a store that an overwhelming number of you said made the most sense; however, none of you wanted it to feel like a direct tax on revenue. So our task was to find something that scales with revenue, but is not directly correlated to it...easy right? No.
We tested things like freemium, with a few core features, and paid add-ons such as number of attributes, seats, storage, and request volumes. It got complicated quickly, and we didn’t like the idea of “nickel and diming” our users, so that went out pretty quickly. We then evaluated free tiers v free trials and have actually ended up offering both! A free trial to try the whole platform and all features and then also a free tier for low order revenue and basic features.
We looked at how we could implement an AWS-style per-usage model, but again it got complicated. It was great at scaling, but no-one (including us) could accurately figure out what an average monthly bill would be for most customers, so again that was out.
Then, we moved on to looking at more traditional SaaS-tiered models. They got really far through our process, as they made a lot of sense, you were all used to seeing them, and gave us a lot of positive feedback. Once we tried to introduce a scaling mechanism to them though, the complexity grew, and understanding the monthly bill got more complicated.
And finally, we found a model based on our old pricing structure, which a number of other SaaS providers (including Baremetrics, Canny, and Onfleet to name a few) are now using that resonated, and ultimately that’s what’s live now.
How it works
Rather than picking a plan that works for you some of the time, we decided it would be best to create something that made sense every month. Which is why we created the stepped model, based on revenue bands - and a simple principle that if you sell more, you’re using more, and we should charge more; while conversely, if you make less, we charge less.
We think of it as a fair exchange of value to run a store with Moltin, and means you only have to answer three simple questions - what’s my revenue? Do I need Flows? Do I need Events? And based on this, you can very easily calculate your monthly bill using the slider on the pricing page.
Due to the banding system, any fluctuations in revenue should never leave you with a surprise bill, and it will scale seamlessly through the lifecycle of your business - from the earliest days, right through to serious Enterprise throughput.
The bands also gave us a seamless way to include free usage of the platform for developers, and hobby projects. We’ve set that as $100 and under will be looking at the data over the next few months to tell us what makes the most sense for that limit.
While this pricing model caters to the majority of you, we recognize this may not be suitable for absolutely everyone. Therefore, if you think you have any special requirements or are pushing through higher volumes than our self-serve model highlights, we're always open to discussing the finer details with you and putting together a custom package to suit your needs.
We’re all really excited to see pricing make a return in a way that makes sense to everyone. During this transition period we’ve made the decision to disable card-entry and package choices via the dashboard while we gather feedback from you before setting it fully live in the coming weeks.
We wanted to give you time to make any adjustments you may need to make to your stores, and liaise with existing customers about moving their existing plans to the new model, or staying with their existing plans for the time being.