4 ms·

Solid idea, after having built N billing portals in the past, I really like the idea of being able to drop in a billing portal. That said -- raise your prices.

by runako 8y ago

Solid idea, after having built N billing portals in the past, I really like the idea of being able to drop in a billing portal. That said -- raise your prices. You might try something that's more explicitly tied to revenue. But if not, I would try the 3 tiers at 39/99/199 (or 49/199/299). Maybe make a 0-10 customer tier that's lower cost. The bigger customers will demand more features to justify the price point, but many of those features will likely prove relatively easy to implement (SSO, 2FA, let them pay you via PO).

raphaelcosta 8y ago
Thanks, @runako! Thanks for your feedback regarding pricing, get tied to revenue could be a great pricing strategy. We got featured on ProductHunt today, would be very nice to have your feedback there also.
- jjeaff 8y ago
  I think if you tie to revenue, be sure to create a cap. Because if your price is going to go up and up forever for something that everyone knows is mostly fixed cost, then people like me are going to be calculating the point that it would be cost effective to do in house and then jump ship when we get to that point.
  - cdolan 8y ago
    I agree here - if you tie to revenu and get too expensive (to me, over $500-100 a month), I’d find the dev time to replace this before we “overpaid”.
    - runako 8y ago
      > over $500-100 a month Businesses come in different sizes, and it's tempting to project startup-level finances onto your customers. But $100/mo is not an expenditure of note at most businesses. (Neither is $1k/mo, but that starts to be a different market.) Some back-of-the-envelope math on costs for building a billing portal: - First pass of Stripe integration including displaying receipts, upcoming bills, edit of payment info, etc. : at least two solid weeks to more like a month of dev time. Yes, most devs can get something shipped much faster. But to achieve a battle-tested, secure, reasonably complete implementation will take a few revisions. A month of dev time in the US will vary, but $10k fully loaded isn't out of the question. If you're using an agency, this could be much higher. Other features your business may want will drive this cost higher: Salesforce integration, QuickBooks integration, operator-facing tools so customer service reps can see what the customer sees, etc. But let's just say $10k+ of dev time for the implementation. Then don't forget you just added a bunch of code to your codebase that will need to be upgraded, tested etc. when you rev platform versions. If you added any dependencies specifically for the billing portal, congratulations on having your billing portal now drive your release schedule. The billing portal adds permanent technical debt to your project without helping you meaningfully differentiate. For a small app, the billing portal code could reasonably be bigger than the rest of the app. I have seen this too. Crucially, while you're building this code, you're not building code your customers care about. Zero of your customers would upvote "build billing portal" over anything relevant to why they are your customer.
ryanwaggoner 8y ago
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
yazr 8y ago
> after having built N billing portals in the past Quick question. Any recommendations for a "wallet library" for a web-app side project (either JS or Java backend) ? Basically we want to take payments from users, charge the wallet for certain operations, and show history and balance. I am not even sure what to google to find this. Any pointers appreciated.
- edoceo 8y ago
  Any ledger software could fit the bill here, double entry journal.

by runako 8y ago

raphaelcosta 8y ago

Thanks, @runako! Thanks for your feedback regarding pricing, get tied to revenue could be a great pricing strategy. We got featured on ProductHunt today, would be very nice to have your feedback there also.

jjeaff 8y ago
I think if you tie to revenue, be sure to create a cap. Because if your price is going to go up and up forever for something that everyone knows is mostly fixed cost, then people like me are going to be calculating the point that it would be cost effective to do in house and then jump ship when we get to that point.
- cdolan 8y ago
  I agree here - if you tie to revenu and get too expensive (to me, over $500-100 a month), I’d find the dev time to replace this before we “overpaid”.
  - runako 8y ago
    > over $500-100 a month Businesses come in different sizes, and it's tempting to project startup-level finances onto your customers. But $100/mo is not an expenditure of note at most businesses. (Neither is $1k/mo, but that starts to be a different market.) Some back-of-the-envelope math on costs for building a billing portal: - First pass of Stripe integration including displaying receipts, upcoming bills, edit of payment info, etc. : at least two solid weeks to more like a month of dev time. Yes, most devs can get something shipped much faster. But to achieve a battle-tested, secure, reasonably complete implementation will take a few revisions. A month of dev time in the US will vary, but $10k fully loaded isn't out of the question. If you're using an agency, this could be much higher. Other features your business may want will drive this cost higher: Salesforce integration, QuickBooks integration, operator-facing tools so customer service reps can see what the customer sees, etc. But let's just say $10k+ of dev time for the implementation. Then don't forget you just added a bunch of code to your codebase that will need to be upgraded, tested etc. when you rev platform versions. If you added any dependencies specifically for the billing portal, congratulations on having your billing portal now drive your release schedule. The billing portal adds permanent technical debt to your project without helping you meaningfully differentiate. For a small app, the billing portal code could reasonably be bigger than the rest of the app. I have seen this too. Crucially, while you're building this code, you're not building code your customers care about. Zero of your customers would upvote "build billing portal" over anything relevant to why they are your customer.

ryanwaggoner 8y ago

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

yazr 8y ago

> after having built N billing portals in the past Quick question. Any recommendations for a "wallet library" for a web-app side project (either JS or Java backend) ? Basically we want to take payments from users, charge the wallet for certain operations, and show history and balance. I am not even sure what to google to find this. Any pointers appreciated.

edoceo 8y ago
Any ledger software could fit the bill here, double entry journal.