⛔ Stop building your auth in-house
I talk to founders every week and the pattern repeats. The team needs login, someone says "how hard can a login form be," and two quarters later they are maintaining an identity system nobody wanted to own and the actual roadmap is on fire.
The problem is that auth looks like one feature but it is actually five products stacked on top of each other:
Every sign-in method your users expect (passkeys alone took our team over 800 engineering hours to get production ready)
Session management that survives a real security review, which arrives with 40 questions you have not thought about
Token infrastructure, issuance, rotation, revocation, the part that pages someone at 2am
Permissions, because plain roles stop working the moment your product grows
And now identity for AI agents acting on behalf of your users, which no in-house auth from two years ago was designed for
Each of these is somebody's entire company. Your team will build all five as a side quest, and then maintain them forever.
My bias is obvious, I do product at an identity platform, of course I would say this. And there are real exceptions. If identity is your core product, build it. If you are Okta, build it (obviously).
But for everyone else, the build decision usually comes from engineers underestimating the boring 80%, password resets, email deliverability, account lockouts, the audit log someone asks for eight months in. The fun part, the login form, is a weekend of the work.
Founders who built auth in-house, how far did you get before the bill arrived?
Replies
@roguetink Hmm the login screen is easy. The years of maintenance behind it aren't . It's one of those problems that seems small until one product starts growing and security expectations catch up.
MonoCloud for Startups
@edward_baker3 Yes, and the security expectations part is what catches people. What was fine at 100 users becomes a liability at 10,000, and nobody plans for the upgrade because login already works. Did you go through this yourself or watch it happen to someone else?
MonoCloud for Startups
the 'how hard can a login form be' line gets me every time because that's genuinely how it starts. 😭
and the bill doesn't always arrive dramatically. sometimes it's just a slow, invisible tax. two engineers maintaining something nobody wanted to own, every new hire has to understand the custom auth flow, every security review surfaces something new, and the roadmap just quietly slips month after month.
by the time it's obviously a problem, you're too deep in to swap it out cleanly. and that's before anyone even asks about agent identity.
MonoCloud for Startups
@riya_pariyar The slow invisible tax is the worst version of it. A dramatic failure at least forces a decision. The quiet one just eats two engineers and nobody ever sits down and asks whether it is worth it, because no single month hurts enough to trigger the conversation. And you are right that the swap gets harder the longer you wait, the custom flow grows roots into everything.
@roguetink This is a classic build vs buy decision . Teams often estimated the cost of shipping auth, but not the years of maintenance, security updates, and support that follow. That's where the real ROI calculation changes.
Kudos on the launch. Everyday i see one product or the other on PH that makes me wonder i should integrate it. and Mono cloud seems one. I have baked in a one click sign-in based on Google Auth. Simple signin + signout. but i am interested in analytics and audit logs. Do you track signup attempts from same device ID, like trial plan abuse? How does migration look like for current setup to free plan?
MonoCloud for Startups
@roopesh_donde Thank you, and good questions. On abuse, we handle it at two layers, brute-force protection that limits failed attempts per user or per IP, and signup controls where you can allow or block by email, phone, or custom regex, so throwaway-domain signups can be filtered before they get in. Audit logs record the authentication events and attempts, so you can see the patterns.
On migration, yours is about the easiest case there is. Google stays the identity source, you plug it in as a social provider with us and your users keep their one-click sign-in, nothing to re-onboard. If you have existing user records to carry over, our Management API lets you import them programmatically with their properties.
Happy to get on a call and walk you through what MonoCloud can do with your setup, the analytics and audit side included.
Also, we are currently taking in design partner startups who get the platform free for one year: https://tally.so/r/ZjKMKB
@roguetink Thanks for answering the questions. Let me evaluate and come back.
The permissions point really resonates. Almost every product starts with simple ,roles, and customer requests turn that into a much bigger system.
MonoCloud for Startups
@jacob_spencer2 Roles are always the sleeper. Two roles at launch feels clean, then one enterprise customer asks for "admin but only for billing" and the whole model bends. What was the request that broke yours, or did you get ahead of it?
absolutely. I see no reason to reinvent the wheel when auth is just a standart part of you product. Use an off-the-shefl solution and launch as quickly as you can.
I would even skip email-password authentication altogether for the first time. That seemingly simple combination creates so many problems that you are better off offering a few Oauth/SSO options alongside email magic links or one-time verification codes.
MonoCloud for Startups
@a1exborsuk Agreed, and skipping passwords entirely is a bolder version of the same call. Magic links and OAuth kill the reset-flow mess and the credential-stuffing risk in one move. The only pushback I have seen is audience-dependent, some older user bases still reach for a password out of habit. Did you get any complaints when you dropped it, or did nobody miss it?
We built in-house auth in the past. It's a never ending story of new functionalities the business keeps requiring, thinking it's simple to add. And then it turns out you need to rewrite the whole thing, because the initial assumptions were insufficient. With time it becomes a mess of authentication, authorization, profile management, identity, etc.
and yeah, "maintaining something nobody wants to own" is a good summary
MonoCloud for Startups
@mateuszkonik The rewrite cycle you describe is the trap in slow motion. The initial assumptions are always insufficient, because auth requirements do not come from your roadmap, they come from whoever your next customer happens to be. Nobody can design for that in advance, which is why the in-house version gets rebuilt instead of extended.
You clearly went deep on this before moving off it, and honestly that is the profile we learn the most from. We are taking on a few design partner startups right now, full platform free for a year, and founders who have lived the in-house mess make the best ones because they know exactly where it hurts. If that is interesting: https://tally.so/r/ZjKMKB, or just reply here and we can discuss it more.
@roguetink thanks a lot. I saw your launch yesterday and your offer seems really interesting. As I am preparing my own launch I don't want to change the provider at the last moment, but I am happy to share my experience if you are interested
MonoCloud for Startups
@mateuszkonik That makes complete sense, the week before a launch is the worst possible time to touch auth, I would tell you the same thing if you asked. And yes to sharing your experience, I would like that, you have lived both the in-house version and the provider version, which is exactly the perspective we learn from. When is your launch? Happy to show up for it.
One thing worth keeping in mind for after, whenever you do look at this again, the move only gets heavier as your user base grows, so the cheap moment to evaluate is soon after launch, not a year in. No rush from our side, the design partner door stays open either way.
Sending you a connection request on LinkedIn, easier to carry this there.