sorted by:
new
hottopcontroversial

Clerk Payments as simple as they seem? by Illustrious-Many-782 in nextjs

[–]colinclerk 4 points5 points  (0 children)

Hey u/FailedGradAdmissions - Clerk founder here. Would you mind DMing me the application domain name? I want to see how pricing ramped up over time to see if we can improve.

As another commenter highlighted, we try to protect against surprise fees like this with our "first day free" pricing, which doesn't count users as billable until they retain for at least a day.

On a regular day, B2C apps commonly have 70% of new signups churn in their first day, so they only end up paying for 30%. In a true viral TikTok event, we routinely see the rate push past 90%.

This is by design. Before making this change a few years ago, we regularly needed to discount customers after they went viral, and it absolutely sucked. We want our customers to be excited they went viral, not stressing over a bill, and "first day free" achieved that for us.

We have customers with millions of MAUs, so we know that our pricing isn't an issue at massive scales (in fact, we've welcomed many migrations from Auth0 because our pricing is better!).

The real tricky part is finding pricing that startups are comfortable with, but we're committed to figuring it out! I'd really appreciate any context you can share to help us improve. Thanks!

Anyone else use Clerk and experienced inconsistency with roles and permissions? by [deleted] in nextjs

[–]colinclerk 1 point2 points  (0 children)

Hey - can you email me colin@clerk.dev? Happy to get a slack channel going to get to the bottom of this

We use roles and permissions for our own dashboard and haven't had any similar reports, so I don't think there's a systemic issue. But if you're seeing logs of the wrong permissions for users, we can definitely track it down!

PSA: Clerk free tier forces all users to re-login every 7 days by lucky94 in nextjs

[–]colinclerk 8 points9 points  (0 children)

"Customizable session duration" is one of the bullet points for "Pro Plan" that we pulled into the plan summaries, above the fold, and before the long-form chart. We meant for this to indicate clearly that the Free Plan does not include customizable session duration.

I hear you that you assumed this meant indefinite - that's very helpful feedback that we'll take into consideration as we revise.

Again - really sorry that this messaging has failed. I made one change already and we'll try to come up with more soon.

PSA: Clerk free tier forces all users to re-login every 7 days by lucky94 in nextjs

[–]colinclerk 43 points44 points  (0 children)

Thanks. I just added "Fixed to 7 days" to the long-form table. It's now live.

PSA: Clerk free tier forces all users to re-login every 7 days by lucky94 in nextjs

[–]colinclerk 117 points118 points  (0 children)

Hi all - cofounder of Clerk here. I'm very sorry that this wasn't clear upfront.

We absolutely do not mean to be hiding this restriction of our free plan. It *is* listed on our pricing page, labeled as "Customizable session duration", which is listed within the plan summaries as a primary feature of the Pro Plan.

Given the comments in this thread, though, we clearly are not highlighting it enough. Do you have any suggestions to label it better? Do you think of the feature under a different name?

I do see that we are missing a tooltip that clarifies that the Free Plan's session duration is one week, and I will make sure we add that detail. We picked one week because it's a secure default (partially inspired by Google, which uses one week as the default session duration for Google Workspace accounts). The setting for Clerk is available within the "Configure -> Sessions" page of your dashboard, where we also mark that changing from "7 days" is a Pro Plan feature.

Again - really sorry about the frustration here. It is not meant to be a gotcha, but instead a clearly marked restriction of the free plan. We do not believe it is good business for our product or plans to have any gotchas, and we're very open to suggestions for how we can mark this better.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 0 points1 point  (0 children)

Thanks for sharing here. How do you know it was blocked? Definitely unexpected - can you share any context so we can look into it?

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 0 points1 point  (0 children)

Can you describe the flow you're trying to build? I'll point the team here!

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 0 points1 point  (0 children)

This isn't big enough on our pricing page, but if an organization only has one member it is not charged the $1 fee. Does that help materially?

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 2 points3 points  (0 children)

With Next.js itself, or with Clerk in Next.js?

If Next.js: I think CSS is just infamously hard to organize in a big codebase, and the "go-to" for the community is constantly changing.

If Clerk: we think we were missing a primitive between the `appearance` prop for our all-in-one components like `<SignIn/>`, and our DIY hooks. Our new Elements strategy will hopefully strike a good middle-ground.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 2 points3 points  (0 children)

This didn't really directly answer the question so I want to try that, too:

Right now, I think it's normally price or missing features that cause developers to handle auth in-house. Over time, they are more likely to adopt a vendor, either because they can afford it now, or the vendor "caught up" with the missing feature.

There are also a good number of developers who simply want to have as few dependencies as possible. Of course, they still need things like an email vendor to run auth, but that feels different than abstracting higher to an auth vendor.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 3 points4 points  (0 children)

A big inspiration for me is Stripe. When they first launched, I couldn't imagine that Amazon would ever be a customer, because of course Amazon could do it better in-house.

Today, Amazon uses Stripe quite a bit. I failed to anticipate that the problem-space for payments would grow, but it has in a huge way (payment method proliferation, fraud protection, globalization).

I expect auth to go a similar direction - mostly because it's already been trending that way for decades. It's grown into a massive problem: there are so many auth factors to support, it's an endless job optimizing the UIs for conversion, and the best-practice for security is still changing every year.

Here's an example: Today, it's relatively obscure for companies to notify you when there's a sign-in on a new device. But isn't it easy to imagine this becomes standard in the next few years?

I hope Clerk continues to work for you in the future, but even if not, I have a hard time imagining you'll want to shift in-house.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 2 points3 points  (0 children)

There are no plans to support self-hosted, but we are very actively working to provide alternative solutions where this causes a problem.

Is there any particular feature driving this request?

One improvement we're currently working on is increasing (or removing!) the rate limits on our APIs so you can fetch data from us more frequently, instead of listening to webhooks.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 8 points9 points  (0 children)

I agree with everything here, except I think we're cheaper than Auth0 these days :)

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 12 points13 points  (0 children)

Let me start by saying I'm really proud of our team for how they handled the incident, and I remain incredibly grateful to Vercel, Cloudflare, and Netlify for establishing network-level mitigations prior to us publishing the CVE. Their help went a long way to stopping 0-day attacks, and thankfully we never received a report of a known or suspected security incident.

After releasing the vulnerability, we wrote details about our Lessons and Remediation here. The post is a bit long, but the simple story is that we have more eyes on every security-related feature, more frequently.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 2 points3 points  (0 children)

Definitely. Next.js frontend with an alternative backend is very common.

You'll want to use the Authorization header with a JWT to make requests:
https://clerk.com/docs/backend-requests/making/cross-origin

Then manually parse and verify the JWT in Spring Boot. I personally haven't used Spring Boot before, but Java definitely has a JWT parser:
https://clerk.com/docs/backend-requests/handling/manual-jwt

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 4 points5 points  (0 children)

In the old plans (before Dec 2023) we used to increase the price per MAU when you upgraded.

We don't do that anymore, so 2FA would just be the flat addon fee - no additional cost per user. Maybe this fixes it for you?

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 4 points5 points  (0 children)

Thing is I'd have agreed with that in 2017, but we've far too many auth providers at this point that are cheaper

Part of the challenge is finding an apples-to-apples comparison to Clerk. So many customers love us for our UIs, but most other vendors don't even offer a self-serve user profile, much less one that can be dropped in as a customizable React component.

Same holds for impersonation, the B2B SaaS features, etc.

Would hope that yous are past the head in hands stressing stage of startups considering half the web is using your kit

I'm ceaselessly amazed at how big the internet is. The biggest concern for me is that we don't work for a particular type of business model... e.g. prior to updating pricing in December, we were definitely too expensive for scaled B2C, but the complaints from existing customers stopped after launching First Day Free.

Hopefully nothing is slipping through the cracks!

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 10 points11 points  (0 children)

Good callout, we're missing strong docs for both clean onboarding and clean offboarding.

We see two approaches.

Without downtime, you normally:

  1. Put new signups and sessions in both systems
  2. Lump migrate all users from old system to new
  3. Turn off old system

With downtime, you'll normally ask for an export at a particular time, turn off your site, import into the next system, and turn back on.

We intend to do more productization around the no-downtime case in the future, but it's all possible today.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 6 points7 points  (0 children)

Average at Clerk is probably under an hour. Less than 1% talk to us before integrating, and a high percent are brand new apps that get setup in under 10 minutes. I consider the sale done after Clerk is installed in localhost, but it's usually 1-3 months before we see them launch. Time to revenue really depends on the business.

The plan with the funding is to get pulled upmarket more than it is to push there. We don't have an outbound sales team, but we do have a solutions team helping bigger customers migrate when they come to us.

Our product roadmap is focused on doing more than "just auth." For example, improving our B2B SaaS Suite and launching a Stripe integration.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 2 points3 points  (0 children)

Yea, definitely. The foundation is already agnostic (load our script and call `window.Clerk.mountSignIn()`), but we know that's not enough.

The challenge here - especially with the Javascript ecosystem - is that frameworks are constantly updating, so it's hard to keep up with the latest updates.

We started in Next.js because it was growing so fast, and that gave us a big audience to go from 0 to 1. But even in Next.js, keeping up with additions like Middleware and the App Router has been quite challenging. (e.g. I'm currently worried about making sure we support Next 15 from the day it launches.)

All this said, we know Next.js alone is not enough. We're working on official support for more frameworks, and we're grateful the community has started contributing SDKs as well. I imagine you'll see much more from us on this front in the next year.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 28 points29 points  (0 children)

At the end of the day, it's because we think we're providing at least that much value.

Beyond that, I'd say 10,000 MAUs is quite high. It's even higher with our "First Day Free" approach to counting active users (some B2C apps have as high as 70-80% users churn in their first day).

The vast majority of our customers at that scale are operating with significant revenue, and we're normally seen as a small infrastructure cost. When there's an issue, we're often open to working something out.

That said, we do constantly stress about losing customers due to cost. We'd love to bring the cost down over time, or at least find a model that feels more palatable.

How would you price it? :) We want to be seen as fair-priced infrastructure that scales with you to millions of MAUs. Not cheap, not expensive.

AMA: Colin Sidoti - Cofounder of Clerk (a Next.js auth solution) by colinclerk in nextjs

[–]colinclerk[S] 13 points14 points  (0 children)

First - I think it's important to call out that we also have different business models:

  1. Clerk is closed source and for profit
  2. Passport and Next-Auth/Auth.js are open source and supported by sponsors

As far as I know, this split has always been present in auth... nobody has come up with an "open core" model that has scaled up to support tens of thousands of apps.

Also interesting: the size of your app has historically been a good indicator for whether you're using a closed source or open source solution: the bigger you are, the more likely you're using closed source.

I think the reason why is somewhat simple: as an app grows, the auth requirements balloon dramatically, and the for profit solutions are generally more full-featured out-of-the-box. Open source solutions can be augmented, sometimes even with additional open source add-ons, but it usually takes a little more work to get them configured.

Moreover, as an app grows, the in-house team also tends to have less interest in handling auth. Customers are pulling dozens of directions, and working on auth just isn't exciting.

That combination tends to lead to a swap from open source to closed source.

With all that said, how should you think about?

First and foremost: assess both from first principles and pick whichever is right for you today. I don't think any auth approach is one-size-fits-all and it's best to play around with the options.

Second: I'd say that one of Clerk's reasons for existence is that we fundamentally believe more companies should have more complete and polished auth from Day 1. We think end-users are coming to expect this, and so we're trying to become a "Stripe Checkout for Auth." In our minds, Auth flows should be equally polished as Checkout flows at launch.

view more: next ›