9
11 Comments

The future of SaaS billing

Let's assume you are CTO of a growing SaaS company, and you are tasked to rebuild the hand-cranked billing solution that is beyond the end of its life. You want to replace it with a state-of-the-art self-service billing solution without spending much effort on your product resources. I'm going to ask you three questions, answer each in your mind before continuing reading. Here we go:

Will you build an in-house payment gateway solution to handle credit card payments?

Of course not. Stripe is the way to go. There is absolutely no reason for any business to be developing a payment gateway solution unless that is their core product.

Will you build your in-house subscription billing solution to automate recurring revenue?

Again, of course not. If you're already using Stripe, the obvious choice is Stripe Billing. If not, there are hundreds of subscription billing tools out there.

Will you build the UI/UX of your billing inside your SaaS platform so your users can see plans, pay, and manage billing info?

Yes, maybe? Your answer is most likely because you have a very custom flow and want it to be scalable and fit the brand. After all, the point was to upgrade the billing to scale with the current growth rate.

If I ask you the last question two years from now, your answer will be an obvious no, similar to the first two answers. Why? Because embeddable customer-facing solutions like Billflow will be no-brainers, just like how payment gateways and subscription billing solutions are currently.

  1. 6

    WOW, another 0.9% of revenue. Any solution that asks for a percentage of revenue can go right fuck off.

    We need Stripe/billing solution because it handles the payments for us. Payments are huge pain, especially cross currency-cross country. Their product management is shit, their functionality is shit, and their usability is shit. But we aren't going to set up an internal payment provider, that's because when it comes to security and payments, we want it done right. Just like you wouldn't in house Auth or encryption, because you are going to get that wrong.

    The answer to your question is Stripe again. This is not a unique value proposition, this is required service on in your payment provider. And surprise Stripe already offers this as well.

  2. 4

    As someone from the EU I'm always surprised at how much everyone loves Stripe for SaaS. In the EU we have so many different tax rules depending on where the customer comes from, if they are an individual or a company...etc That it makes no-sense to use Stripe. There's an article about the pain we have to go through here: https://stefanbauer.me/articles/the-hell-of-taxes-when-building-a-saas-in-europe

    I personally use Paddle across my products to avoid these headaches!

  3. 3

    UI/UX for billing is going to be permanent part of the SaaS application. Why one should keep paying with revenue share for it ?

    Don't make any sense. One of the key responsibility of CTO is optimization. Why would he/she choose to pay a revenue share rather than paying maximum 1 month salary of a employee ?

    Also in most cases Stripe will not be 100% plug and play. There is a need of coding using webhook and API.

    So Billflow is solution who don't know coding or whose product is still in MVP. After the product matures , the first 3rd party service to be kicked out of the stack is BillFlow.

    1. 1

      The number of resources billing integration will consume out of your team depends on the size of your organization. It can start with a 1 month of salary all the way to an entire team working full-time on revops!

      A tool like Billflow is not optimal for a solo founder who is just building their product and gaining initial traction, in fact, you shouldn't even be building a scalable billing solution at this point. Do the things that don't scale at first.

      Yes, the revenue sharing is always painful, but any price is always a % of your revenue. It can only be justified if you feel the pain point.

  4. 1

    These services are great for people that don’t know how to code or quick mvps.

    But no sensible CTO would use a template based service on top of their billing layer and lose 0.9% of their revenue to save a week of development.

    Not going to happen.

    The argument of this post is built on a false premise.

    Replacing Stripe would be a near impossible task, so paying their fees is the obvious choice.

    Replacing some UI/UX? A week or two.

    1. 1

      I wrote this point directly from a customer interview I did with a CTO of a successful growing SaaS company who saved three months of development by using Billflow and Stripe.

      It may take a week or two to build a billing UI integration with Stripe for a solo founder. In fact, I advise on not even spending that time and do it manually or use the out-of-the-box Stripe hosted pages until you are ready to scale your billing.

      1. 1

        Time saved is specifically the metric you often optimize for at an early MVP stage. That's why a lot of people use no-code tools to prove concepts.

        Ultimately, building a visual pricing page or a plan selector is a trivial task whether you are a solo technical founder or a SaaS company with a dedicated product team.

        It's not a question of "If", rather "When".

        I advise on not even spending that time and do it manually or use the out-of-the-box Stripe hosted pages until you are ready to scale your billing

        Exactly, that's what I and others have pointed out already. When you are just starting out, you should use available shortcuts. It's different when you are an established CTO, and I don't see that changing anytime soon.

        When you scale, you invest the necessary resources to own your billing experience, not cut corners by using a no-code tool that will shave your revenue by an additional percentage.

        1. 1

          I guess we both agree to disagree on the fact that no-code tools will or will not be used by larger organizations in the future.

          It is not about cutting corners, it is simply about saving time and focusing on the core product. No-code tools are the future, and as they mature in their verticals, they will be adopted by larger companies.

          I disagree that as you scale you will want to build your own billing experience. Yes, you will want your own custom billing experience, but not necessarily want to build it your own. My hypothesis about the future is based on the historical fact of build versus buy in SaaS companies.

  5. 1

    This post makes quite a lot of sense for sure, @darafsheh. Billflow looks pretty great! I'll surely check it out for ruttl

    1. 1

      Thank you! Let me know if you need any help :)

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 14 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments