Today, after a couple of months of testing and research, r4nkt officially opened up for business. That is to say, plans and their major features were selected, pricing was determined, and the site was updated as such.
In selecting plans, we wanted the differences between them to be as few as possible and to be something that made sense for the customer as well as for r4nkt.
Initially, we looked at imposing limits on the various gamification resources. R4nkt has resources like achievements, rewards, leaderboards, and players. This seemed like an easy place to start. But, any limits that were selected seemed somewhat arbitrary and very likely to be a bad fit for a lot of potential customers. Some customers might want to define a lot of achievements or maybe they have a lot of players, but they wouldn't actually expect to see much in terms of player activity. Other customers might just want to define a few achievements, for example, but would expect to see a great deal of player activity. So, customers like these would have to pay a lot more for what they would be getting, in terms of features, than they would actually need or use. Or, at a minimum, they might feel this way, and that is something we would rather avoid at r4nkt.
Over and over again, however, we kept coming back to the number of API requests as a way to measure usage. This seemed to translate quite well for us in determining price and for the customer in determining which plan to use. It seemed much more natural for our anticipated customers, too, in a way where each customer seemed more likely to feel like they could make a great choice for their particular project.
It's true that some customers might define a massive amount of resources, but we have some reasonable limitations on the big "resource hogs", which are r4nkt's action triggers and nested criteria groups.
The only other aspect that we considered worth using as a distinction between plans was the number of team members that one could have. All subscriptions are team-based, but we thought it made sense to limit the lesser-priced plans to fewer team members than the greater-priced plans. Our conclusion from the feedback we received is that customers that anticipated a higher amount of player activity also had a greater interest in support for larger teams. Those that anticipated a lower amount of player activity didn't have the same kind of interest when it came to team member limitations.
So, the other side of this coin has to do with costs, of course. At a high level, r4nkt's costs come from usage, which is primarily from storage and compute time. After observing how the service is used, determining the costs on a per-request basis was relatively straightforward. And so, without getting into details, it was a simple matter of basic mathematics to calculate our anticipated costs, which then pointed us to where we should be looking to set our prices. Coupled with a few other factors, some concrete plans started to emerge...plans that we were confident would be good for our customers, good for r4nkt, and easy to understand for everyone.
A final point to make has to do with the future. R4nkt has an obvious interest in staying in business, as well as a goal of making good sense to its customers. A fair price will always be charged, but that doesn't mean that there can't be flexibility in how it delivers its services.
R4nkt will continue to look at usage and costs. R4nkt will continue to listen to our customers' feedback and suggestions. We will make adjustments going forward to our plans, but they will always -- hopefully -- be clear, simple, and fair. R4nkt will always be good value for money.
Check out r4nkt. Follow us on Twitter. Let us know what you think. 🤓
(Originally posted at https://www.indiehackers.com/product/r4nkt/open-for-business--MUyRHYgpS6pxmHTOCH0)
Top comments (0)