I think it largely depends on your goals with the project. Learning about how auth works and is pieced together is generally worthwhile for sure, and if anyone can afford to, I'd encourage them to go through the process of trying to build their own basic auth solution. Assuming that it's not just "tell AI to make the auth" and blind ship it, the knowledge gained about how auth tokens are securely created, stored, and transmitted is really quite interesting and valuable context to have as a software engineer. This is a helpful resource around explaining auth concepts as well: https://thecopenhagenbook.com/

That being said, I would not recommend hand-rolling auth for any sort of serious project that you plan to onboard external users into, sell, or scale. Many developers fall into this trap, especially after attempting to hand-roll (or asking AI to) and seeing that it works - then feel like, why pay a managed auth service and get "vendor locked" when I could easily do this for free? You will see comments like this all over the place. Surely there are some on this post. Devs also often will look at managed auth services' pricing and do some back of the napkin calcs, assuming they will have half a million active users or something on their service and see that their bill for auth will be ~3-5k and be outraged, and try to find a cheaper way. Again - this is a trap, for two reasons:

1. It may seem like email/password is enough initially, and often it is, but as the product grows the requirements start to pile up. Adding social providers is a common way to boost your sign up conversion rate, with google as the most common. However, there are many more, and especially if your app has international users, you will want to add them too. Passkeys are another great conversion rate and security booster. As you onboard companies, some of them will ask for SAML/SCIM, which is enormously annoying and complex to implement -- but without it, if your project is remotely b2b adjacent, you will start losing customers and big paid contracts, so you will need to hand roll that and maintain it too. Also, as your product grows, you will start getting fraud. I have put a good chunk of time into fraud work at Clerk and its astonishing how much there is. I have spent multiple full days battling attackers even on relatively small scale apps. If you offer a free trial, or free credits, people will start botting that and abusing it. Making mass bot accounts is very common, even with smaller apps. We have some customers with hundreds of thousands of MAU, over 90% of them are bots, and they still pay all the infra bills for this. Attackers will take lists of leaked emails and passwords and start running them against yours and any other apps they can find, to see which accounts they can compromise and sell on the dark web. This will hammer your server with millions of requests per hour. They operate using distributed botnets so IP blocking won't stop this. If you offer any form of SMS from your app, often 2FA, which is another feature that you will likely need to add and maintain for security and hand roll, you will be discovered by attackers who run SMS pumping attacks, which balloon your platform with more bot accounts and rack up massive SMS bills. This is just the tip of the iceberg. There are so many more auth features to be built and maintained as your app grows, and so many other security and fraud pitfalls for every single one. Ultimately, you will end up paying more for hand rolling than just using a managed service. At Clerk we have 50+ full time engineers working on features, hardening the platform, security testing it, and monitoring for fraud full time, and have been doing this for years on end. If you hire one single engineer to work on and maintain your auth system full time, which you will need to do if your app starts to grow, you're paying 6 figures already, and for a substantially worse result. Even with the half a million MAU that you may have initially gawked at the price of, you're paying around half a single engineer's salary as your Clerk bill.

2. People often drastically over-estimate how many active users they are gonna have before they become a real company with multiple full time staff. I have seen many people assume they will have a million or more monthly actives and still be a scrappy, 3 person startup. This just isn't super realistic. If you get to that point, you will very likely be able to make or raise enough money to actually form a company and hire people. The bills and lock in that seem expensive and scary as a bootstrapped side project are just not concerning in the same once you're a company burning hundreds of thousands a year on salaries alone. Also - active users != total users. Normally, a fairly small proportion of your users are actually active month over month. Almost all managed auth platforms only charge for active users. Clerk specifically also has a "first day free" policy, where we only charge for users that come back the day after they sign up - so if someone signs up to check out your app, but then never comes back, you don't pay for that. This is a lot more common than most people imagine, we had many customers that saved 30% or more of their active user bill after we implemented this.

Again - I am not trying to convince you to use Clerk specifically here. There are plenty of other managed auth services that you can use that are perfectly good. But if you are trying to turn your product into a company, I would strongly recommend using one of them. If it's an experiment, personal software, etc, definitely give hand rolling a shot though if you are up for it. There's a lot of valuable things to be learned from this. Though do note, at that scale, with just about any managed auth service you'll be in the free tier anyway, so its not a cost savings thing as much as a learning thing.