Spryker Pricing Reloaded
We have just introduced a new pricing model for the Spryker license. Customers no longer need to purchase a project- based Spryker license, as they can buy “developer seats” on a monthly basis instead, depending on how many developers are using Spryker in a particular project. Pricing per developer or user may not be new in the world of software licensing but it is certainly new for our industry, especially as no other costs are involved. Here’s why we have decided to bring in the new pricing strategy!
How did we come up with our first pricing model?
We started Spryker in November 2014. Back then, we carried out a lot of research into the existing pricing models in the enterprise software market and we put our own experience into the equation. We knew that all models that charged the customer based on their revenue were facing headwind from them. No customer wants to spend €10 m+ on a TV campaign, only to have to share the profit with the software vendor. It just simply does not make any sense for 5 m+ e-commerce businesses nowadays. In addition, the method vendors employ to determine prices does not establish a foundation of trust with customers. Customers knew that they were getting an individual price based on what they could afford. It basically came down to the sales rep selfishly deciding which price works best. We wanted to be more transparent and comprehensible. In order to avoid complexity, we also decided against charging based on servers (staging, production and so on). We ultimately tried to figure out what kind of leverage the Spryker code would offer our customers and ended up with the €100,000 per project, per year mode, based on a typical 4- year contract. The only variable in that pricing model was the number of permitted frontends per project, but our pricing basically amounted to 100k per year.
What have we learned?
The old pricing model worked pretty well for us in the beginning. Customers with very limited budgets tended to avoid Spryker, which was then and still is fine, because the solution catered for companies with at least 3-5 developers (in-house/external). Other (larger) customers accepted the pricing on the spot as it was much more attractive in comparison to other enterprise solutions. However, the old pricing came with two critical problems. The first relates to our business model. We could not grow our revenue with our customers’. Even in the event that a customer only started with 3 developers and then expanded to 100+ developers and €100m+ revenue, the pricing would stay fixed. This does not make good business sense if you take into account that 100+ customer developers would lead to many more support resources on our side. Furthermore, customers naturally wanted to know what kind of new features or services we will offer in the future for the upcoming €100k per year. All we could say at that point in time was: “Something very relevant for our customers, based on their demand.” When we asked what our customers would need in two or three years from now their answer was: “We don´t know. Our markets are very versatile and therefore is not predictable. We will tell you in the future.” That was kind of a dilemma when we tried to write down the terms on paper. In the end we figured out that the industry-wide, 4-year contract time does not work for modern e-commerce projects and that a contract without some flexibility for scaling up and down is not the best model for us and our customers.
How do we solve this in the new pricing model?
The new model allows customers to buy developer seats per year (€15k) or per month, depending on their needs. This includes all patches and upgrades of the Spryker core. The only extra service is an SLA which can be bought for €25k/year and provides a specific level of response and solution times in the case of software bugs. The reason behind this pricing is that customers who frequently use Spryker (=many developers) pay more and other customers pay less, while all negotiation risks are eliminated. Customers can just start a project with Spryker and end it after a few months if they find another/better solution for them. Even customers with 10+ developer seats might come to a stage where they only want to maintain the Spryker code but move on to another tool or solution as time progresses. In that case, one developer could be enough for the maintenance work. We think the worst pricing strategies are those which include some kind of lockup contract where customers are forced to pay for a multi-year license, even if they no longer use the service. Our motivation behind this model will be to offer top-notch code, so that customers will be glad to buy developer seats. If they stop buying, we probably will have some issues with our product.
The e-commerce entrepreneur Alain Veuve called this approach “Customer Centric Pricing” in a recent blog post about our new model.