4 ms·

Great idea. Charge more. Get rid of the $9/plan. Saying this as a SaaS operator who could use something like this, and who pays much more for other apps.

spreadr 5y ago
Thank you! I just got a very similar suggestion. What according to you should be the minimum pricing tier?
- stevoski 5y ago
  A good place to start with pricing is tiers at $49/$99/$249. (As recommended in Jason Cohen’s classic and awesome talk “Designing the Ideal Bootstrapped Business”: https://youtu.be/otbnC2zE2rw https://youtu.be/otbnC2zE2rw) Customers at very low price points (such as $9/month) tend to churn quickly, and, counterintuitively, send more customer support interactions per customer than at higher points. You’ll never earn enough from them to cover your customer acquisition costs. Getting rid of the cheap plan also removes the, shall we say, more difficult customer.
  - spreadr 5y ago
    Thank you so much for this!
unknown_error 5y ago
TLDR, IMHO: Get rid of the Small plan, make the Sandbox tier a much more generous free tier (1k/10k with logo), and charge more for the bigger plans. "First one is always free" kinda thing, so that devs can use your service for small projects (that don't cost you much) but then upsell it for broader enterprise-wide adoption on bigger projects. As a dev, I have the opposite opinion: The low-end pricing is a barrier to adoption. $9/mo isn't much, but it's the difference between "Oh cool, I can immediately use this in some of our side projects!" and "Oh, I have to request budget approval for this, explain what it is to superiors who might not be in the IT dept, answer questions about why we don't do just build it ourselves, answer questions about vendor support and lock-in, etc." It would cost more time for me to jump through all those hoops than to just use a standard CSV parsing library -- even though the workflow is vastly inferior -- because it's much less bureaucratic. Other services often provide a more generous free tier so that devs (the first ones to try something, often) can use it in a real-world project, fall in love with it, and then sell the paid version (which could be much more than $99) to their superiors only when the prototypes have proven valuable enough to make a solid sales pitch. I'm not a business consultant by any stretch, just letting you know that as a dev, I'd probably never bother using this because of the bureaucratic headaches involved with your pricing structure. Just my 2c.
- unknown_error 5y ago
  Forgot to say: If the computing resources don't cost you that much, consider making higher business/enterprise plans where you sell an SLA and/or support contract and/or custom feature development/integrations, etc. rather than making it usage-based.
  - spreadr 5y ago
    All of this makes a lot of sense. We will surely have a relook at the pricing model.

spreadr 5y ago

Thank you! I just got a very similar suggestion. What according to you should be the minimum pricing tier?

stevoski 5y ago
A good place to start with pricing is tiers at $49/$99/$249. (As recommended in Jason Cohen’s classic and awesome talk “Designing the Ideal Bootstrapped Business”: https://youtu.be/otbnC2zE2rw https://youtu.be/otbnC2zE2rw) Customers at very low price points (such as $9/month) tend to churn quickly, and, counterintuitively, send more customer support interactions per customer than at higher points. You’ll never earn enough from them to cover your customer acquisition costs. Getting rid of the cheap plan also removes the, shall we say, more difficult customer.
- spreadr 5y ago
  Thank you so much for this!

unknown_error 5y ago

TLDR, IMHO: Get rid of the Small plan, make the Sandbox tier a much more generous free tier (1k/10k with logo), and charge more for the bigger plans. "First one is always free" kinda thing, so that devs can use your service for small projects (that don't cost you much) but then upsell it for broader enterprise-wide adoption on bigger projects. As a dev, I have the opposite opinion: The low-end pricing is a barrier to adoption. $9/mo isn't much, but it's the difference between "Oh cool, I can immediately use this in some of our side projects!" and "Oh, I have to request budget approval for this, explain what it is to superiors who might not be in the IT dept, answer questions about why we don't do just build it ourselves, answer questions about vendor support and lock-in, etc." It would cost more time for me to jump through all those hoops than to just use a standard CSV parsing library -- even though the workflow is vastly inferior -- because it's much less bureaucratic. Other services often provide a more generous free tier so that devs (the first ones to try something, often) can use it in a real-world project, fall in love with it, and then sell the paid version (which could be much more than $99) to their superiors only when the prototypes have proven valuable enough to make a solid sales pitch. I'm not a business consultant by any stretch, just letting you know that as a dev, I'd probably never bother using this because of the bureaucratic headaches involved with your pricing structure. Just my 2c.

unknown_error 5y ago
Forgot to say: If the computing resources don't cost you that much, consider making higher business/enterprise plans where you sell an SLA and/or support contract and/or custom feature development/integrations, etc. rather than making it usage-based.
- spreadr 5y ago
  All of this makes a lot of sense. We will surely have a relook at the pricing model.