7
20 Comments

The SaaS founder’s dilemma: auth + billing

I’ve been stuck for the last days on authentication & payment for my SaaS.
It feels like a total productivity killer. I know I should probably just keep building features. But at the same time, these are foundational blocks. You don’t just swap them out later.

The dilemma:

  • Solutions like Clerk or Kinde look almost perfect (auth + billing in one place, ready-made components, super easy and quick integration).

  • But then there are blockers: Clerk only offers US hosting, Kinde misses some features I’d need (annual payments, free trials).

  • Splitting it up (Stripe + separate auth provider) gives me more flexibility, but adds more moving parts.

Meanwhile I’m trying to also build traction (website, waitlist, social media) — so it feels like I’m juggling too much at once.

Curious to hear from others:

  • Did you start with an “all-in-one” solution or keep auth and billing separate?

  • How much time did you spend on this decision early on vs. just moving forward?

  • And if you had to switch later — how painful was it?

posted toAvatar for product Filently
Filently
  1. 2

    Recently launched a SaaS, I had the same dilemma. I considered Clerk for auth, and different payment solutions. I really liked Paddle, but in the end I went classic with Stripe because it seemed more flexible and rates per transaction were lower. For auth I ended up with the built-in auth from Supabase, mainly to avoid bringing too many things and keeping it simple.
    As for billing, for the moment I am offering 30 days free trial, and I ask for payment details only when trial ends. Not sure yet if its the best approach, many recommend asking for payment details right on sign up, but on the other hand I don't want to add an extra "obstacle" before users try the app. I might change this in the near future.

    1. 1

      Thanks for sharing your journey.

      Regarding the trial in my previous company we required to enter the payment details also for the free trial at first and changed it some weeks later to ask for payment details only when upgrading. It has pros and cons: with the first approach we got more payed users, but the churn was high. With the second approach we got more registrations but less payed users.

      Lessons learned? I'm still unsure. I also think it depends on your product and your marketing.

  2. 2

    You might consider the open source Better Auth (better-auth.com) for auth, and an MOR like Lemon Squeezy or Paddle for payments. It enables keeping auth under your control, and you can investigate payment providers separately.

    1. 1

      yeah, meanwhile I'm close to splitting it up.

      1. Auth: Why would you go with Better Auth instead of using an external auth provider? Until now I tended to externalise auth data for security / risk reasons.

      2. I already thought about an MoR but as Stripe is the most common and flexible (also regarding existing integrations) solution, I thought to go with Stripe.

      Looking forward to hear your opinion on that.

      1. 2

        <apologies, this is super late, you've probably solved all of this by now>

        1. Auth: One upside with Better Auth is that auth is completely in your control--your user data never leaves your servers, and you aren't dependent on some other company staying in business, etc. The tradeoff is, as you mention, you're handling the security.

        1. MoR: right, it's a set of tradeoffs around hassle with payments/taxes/etc.

        1. 1

          Thanks for your reply anyways … it's not too late as for the payment provider. As for auth I decided to go with Kinde.

  3. 2

    Regarding billing I went for stripe but mainly because I've never seen anything else in action..auth is a pain..my whole infrastructure is on Aws so the obvious choice for me was Cognito, but Firebase Authentication would probably be my second choice.

    1. 1

      Well I have used other than Stripe before, but it's fact that a lot of SaaS use Stripe so it's pretty well known, also for users. So yeah, that's why I also now tend to just use Stripe.

      For Auth I'm still unsure. Yes, it can be a pain so I want to use a service that's just working. Currently I tend to use Kinde (without the billing for now).
      Firebase Authentication was not on my list yet 🤔

      1. 1

        Yeah, Stripe basically became the de facto standard it seems..in my future project I'll try and force myself to test something new, let's see how it goes :)

  4. 2

    Great breakdown. I’m curious — if you went all-in-one now and had to switch in 6-12 months, which part do you think would hurt most: auth or billing?

    1. 2

      Very good question! I have migrated subscription data twice. The last time for 500+ customers – from our own solution to a dedicated subscription service. It was a nightmare.
      On the other hand: in the beginning I plan to add only social login. So this might be easier to migrate (depending on what other features I'll use).
      So it's hard to say, but I would say billing would be more painful.

  5. 2

    Been there! My take: don’t overthink it, launch with the fastest setup you can, but document your billing assumptions clearly (trials, discounts, usage). Migration pain comes more from messy logic than from the tool itself.

    Later, if you need advanced stuff, there are dedicated billing platforms (e.g. Saaslogic) that can handle more complex scenarios. But for now, just move forward and keep building traction.

    1. 1

      Thank you for your words. Gives me a bit peace. I tend to overthink stuff and I know it. 🙈

  6. 2

    Payment solutions can be hard. I use Paddle for payments, but took a few days of solid focus on only that to get it up and running.

    1. 1

      yeah, I can imagine. I implemented payment / subscription before in my previous company, I know the pain. That's why Clerk and Kinde sounds so nice, but still lacking features I'd expect.

  7. 1

    I agree that these things are harder than they need to be. Consider some vibe coding tools to simplify. I used lovable for my last project and was able to build Auth with supabase and stripe checkout / billing in about 2-3 prompts. I haven't tried doing the same with Claude Code, but based on its performance, I would bet that you could get similar results. I tried the same with Cursor and got lots of garbage that took me a super long time to clean up.

    1. 1

      Yeah, meanwhile I'm also tending to use Stripe and separate Auth. Should be not too complex integrating it with Claude Code.
      TBH: I've never tried Cursor. I'm quite happy with Claude Code (and I'm sure I could still improve my workflows).

  8. 1

    This hits me close to home- I'm already thinking about how to balance being transparent with users while still charging fairly. How did you personally decide when it was the right time to start billing users, and how did you communicate it without losing them?

    1. 1

      I'm not live yet but I will charge immediately, offering a free trial. Well, I probably invite the very first users from the waitlist to try it for free for 1 - 3 months if they are willing to provide feedback and talk about their needs. It's good to let them know in advance about the conditions.

      What is your situation actually?

      1. 2

        Thanks for asking! i'm actually live already - The SaaS that i have already built(Optigain), right now am offering it completely free while i collect feedback and improve it , but am planning to add a 7-14 day free trial before moving to a paid plan (probably around $49/month)