5
10 Comments

Complex pricing: how to handle?

We are planning to launch a SaaS/PaaS soon, mostly API. However, due to the nature of the service, the pricing, or better said, the limits of each plan, may be a bit complex.

Imagine we are offering an API for Machine Learning, then the plans depends of the amount of models, type of model, number of features, type of features, complexity of features, size of features, etc. Because according to these things, we need to allocate resources.

What is your suggestion on this case? Make plans with a lot of margin, making some prices a bit expensive if you are not using all the resources, or granular pricing? We are kind of lost on this...

on January 27, 2022
  1. 1

    Could you have a resource calculator with sliders on. Each plan provides a number of "points" and you assign a set amount of points per metric / usage amount.

    Max one slider up and others have to be lower, or you pick what you want and it says how many points / credits are required and tells you a suitable plan.

    Also what is the target market, price too low and might look odd for the effort I'd they have to have developers to consume the api being paid a lot more.

  2. 1

    If you're just launching, I think you should keep your pricing as simple as possible. Choose one unique usage variable and model your pricing around it.

    At Progressier, I had a somewhat similar thought process when designing the pricing.

    It's a script you embed in your site. So the actual cost depends a lot on our customers' traffic, the number of push subscribers they have, how often they send notifications, how much they use our API, etc.

    I have customers costing me $50 a month and others only $0.50. And I charge both $15/month anyway. The model works because I have a lot more of the latter than the former.

    Customers don't get more value from the product just because they have a higher traffic (in my case at least). So including all these usage variables in the pricing model would just make things unnecessarily complex.

    So instead, it's just a flat fee per app with everything else unlimited. I just have one unique upper limit (50K subscribers per app), so that if someone comes with a gazillion users, I still have a reason to charge them more.

    Try value-based pricing instead of cost-based pricing. Just abstract your actual cost and charge more only when customers get more value. Simplicity is everything.

  3. 1

    Have you looked at resource based pricing? Pulumi has an interesting pricing model which I find quite intuitive even though it’s for a relatively complex product.

  4. 1

    Because according to these things, we need to allocate resources.

    Why not charge by resource usage.

  5. 1

    Rate limiting can help. But you should consider adding a base price. Base price can be included rent of algorithm and data amount also the hardware which your project runs on.

    For example running the algorithm for 10 sec for 10mb data is 0.05$, and you should add this the base price.

    Also your pricing will become visible when you actually provide the service. Keeping the price same for old users for couple of months and change the price can be understandable.

    On the other hand you could decide a monthly payment and add a rate limiter.

    The AWS approach is acceptable I guess. You could check dynamodb's pricing. They decided to calculate read and write differently with size of data. When you write more than 4kb data at once price mutliplied by 2. Also they have performance threshold, when you reach that threshold, you get throttling errors.

  6. 1

    What do other companies of your size do in your target market? That might be a good starting point.

    1. 1

      They have very expensive plans (one of them, the smallest one is $200), which I think it isbecause to have large margins and dont care about small details. But we want to aim to small companies, providing plans as low as $10.

      1. 1

        Can you make a profit selling to them? Having customers that are willing to pay large sums can make your lives a lot easier.

        1. 1

          We can as long as they respect the limits for the plans. But if we have to create different plans for each limit the pricing may become complex.

          1. 1

            If your plan costs $10 and we assume you make $5 profit off of that, you need 1000 small businesses to sign up for your service to get to $5k in profit.

            If your plan costs $300 per month and you make $250 profit off of that, you need only 20 medium sized businesses to sign up for your service to get to $5k in profit.

            What do you think is easier to get? 1000 business or 20? Also consider that in the second case you'll be able to spend money on marketing. In the first case, your margins will make that very hard.

            Honestly, I'd recommend copying the pricing of your competitors and selling to people who actually value the service you provide and are willing to pay money for them.