3 ms·

Probably not true for everyone, but I would never implement this if it took a percentage of revenue. I made that mistake once. This is a very basic SaaS feature

Probably not true for everyone, but I would never implement this if it took a percentage of revenue. I made that mistake once. This is a very basic SaaS feature you can build out once and rarely think about again, or just grab a prebuilt starter SaaS setup like the ones I know of for Rails or Laravel and start with that. So I’d be on the fence about a monthly fee to begin with. But a percentage of revenue? Hell no! Edit: plus, since you’re not driving new revenue, and replacing you is a one-time-fee (maintenance for this feature is minimal), all you’re doing with pricing based on percentage of revenue is pushing your largest and most valuable customers to get rid of you as fast as possible.

raphaelcosta 8y ago
Sure, I was imagining not a percentage of the revenue, but plans based on how much revenue they are making with their SaaS tool. Ex.: If you make more than 10k MRR, you need to be on the Business plan.
runako 8y ago
I should have been more clear that I meant a linkage with revenue, which does not necessarily need to be a percentage. This helps at the high end and low end. Just quickly noodling this, I might define buckets based on revenue: - free until revenue hits $X/mo (versus # of customers, this better tracks ability to pay) - buckets defined as revenue of $X-$Y pays $Z - max revenue tier is $X/mo, BUT - pricing can go higher with more value-added services. Really common examples: SSO, Salesforce integration, QuickBooks integration, we'll call customers to find out why they churned, we'll proactively handle renewals of your customers who pay by PO (this is a PITA), and other things your $$$$$ customers will ask for. Also: no pricing model will work for every one of your potential customers. And it's easier to lower prices than raise them.
geku 8y ago
Do you mind to list the existing starter setups in Rails/Laravel? Thanks.
- ryanwaggoner 8y ago
  Here’s a thread that might be useful: https://www.indiehackers.com/forum/recommendation-on-a-saas-boilerplate-project-8a1ebd14f8 https://www.indiehackers.com/forum/recommendation-on-a-saas-...

raphaelcosta 8y ago

Sure, I was imagining not a percentage of the revenue, but plans based on how much revenue they are making with their SaaS tool. Ex.: If you make more than 10k MRR, you need to be on the Business plan.

runako 8y ago

I should have been more clear that I meant a linkage with revenue, which does not necessarily need to be a percentage. This helps at the high end and low end. Just quickly noodling this, I might define buckets based on revenue: - free until revenue hits $X/mo (versus # of customers, this better tracks ability to pay) - buckets defined as revenue of $X-$Y pays $Z - max revenue tier is $X/mo, BUT - pricing can go higher with more value-added services. Really common examples: SSO, Salesforce integration, QuickBooks integration, we'll call customers to find out why they churned, we'll proactively handle renewals of your customers who pay by PO (this is a PITA), and other things your $$$$$ customers will ask for. Also: no pricing model will work for every one of your potential customers. And it's easier to lower prices than raise them.

geku 8y ago

Do you mind to list the existing starter setups in Rails/Laravel? Thanks.

ryanwaggoner 8y ago
Here’s a thread that might be useful: https://www.indiehackers.com/forum/recommendation-on-a-saas-boilerplate-project-8a1ebd14f8 https://www.indiehackers.com/forum/recommendation-on-a-saas-...