How to Choose Between Building Your Own Auth or Buying It — Before It Costs You Six Months

Authentication is the decision that bites founders in the arse more consistently than almost anything else in a SaaS build. Not because it’s technically exotic – it isn’t – but because it looks deceptively simple at the start, and the cost of getting it wrong compounds quietly until one day you’re six months in and your engineer is explaining why adding SSO for your first enterprise client means rebuilding half your session layer. We’ve seen this play out enough times that we now treat the auth conversation as a first-week decision, not a footnote.

So here’s the honest call: when should you build your own authentication, and when should you buy it? The answer is almost never purely technical. It’s about where you are in the product lifecycle, who your customers are, and what you can afford to own in the next 18 months.

Why Founders Default to Rolling Their Own (And Why That’s Usually Wrong Early)

There’s a certain kind of technical founder who finds authentication intellectually satisfying. JWTs, refresh token rotation, bcrypt rounds, session stores – it feels like real engineering, and it is. The problem is that building auth properly takes longer than anyone budgets for.

When we scope a greenfield SaaS build, a well-implemented custom auth system – email/password, email verification, password reset, basic session management – runs somewhere between 25 and 45 hours of engineering time before you’ve written a single line of your actual product. Add MFA, and you’re looking at another 15-20 hours. Add social login (Google, LinkedIn, whatever your customers actually want), and you’re at 60-80 hours before you’ve touched the problem you set out to solve.

On Australian mid-market agency rates, that’s $12,000-$22,000 of runway spent on infrastructure that has nothing to do with your value proposition. For an early-stage founder trying to validate whether anyone will pay for the thing, that’s a dangerous place to sink money.

The mistake we see most often isn’t that founders choose wrong – it’s that they don’t make the choice consciously at all. They start building login screens on day one because “everyone needs login” and three weeks later they’re debugging password reset edge cases while the feature their investors actually care about sits untouched.

The Bought Options Are Better Than They Were, But They Have Real Limits

Auth-as-a-service has matured considerably. The main options Australian startups use are Auth0, Clerk, Supabase Auth, and AWS Cognito – and they’re genuinely different products for different contexts.

• Clerk is the fastest to ship with, especially on Next.js. Opinionated, beautiful defaults, good DX. The pricing model changes character once you have meaningful MAUs, and the vendor lock-in is real – your session model is Clerk’s session model.
• Auth0 is enterprise-grade and has every feature you’ll ever need, including SAML and enterprise SSO out of the box. It’s also genuinely complex to configure correctly. We’ve seen teams spend more time wrangling Auth0’s rule and action pipeline than they would have spent building what they needed directly.
• Supabase Auth makes sense if you’re already on Supabase’s Postgres infrastructure. It’s open-source, you can self-host if you need to, and it handles the common cases well. It’s less full-featured than Auth0 but the integration overhead is minimal when you’re already in that stack.
• AWS Cognito is cheap at scale and integrates well if you’re deep in AWS. The developer experience is, to put it charitably, an acquired taste. We avoid it on early builds unless the client has a specific AWS dependency already in place.

What none of these solve cleanly is highly custom authorisation logic – not authentication (who you are) but authorisation (what you’re allowed to do). If your permission model is anything more complicated than role-based access with three or four roles, you’ll end up writing meaningful custom code on top of any of these services anyway. That’s not a reason to avoid them; it’s a reason to understand exactly what you’re buying.

The Inflection Points That Change the Answer

The build-vs-buy call should be revisited at three distinct points in a product’s life, not just made once at the start.

At MVP stage: Buy, unless you have a specific regulatory reason not to. Your job is to validate the product, not to build perfect auth infrastructure. The exception is if your target market is enterprise from day one – in which case you need SSO support before your first demo, and that changes the calculus on which bought solution to use.

At first enterprise contract: This is where the bills come due. Enterprise customers will ask for SAML SSO, and they’ll ask for it before they sign. If you’re on a provider that charges for enterprise SSO as a premium tier (Auth0 does; Clerk does), you can be looking at hundreds to low thousands of AUD per month before you have the contract value to justify it. We’ve had clients hit this wall mid-negotiation. At this point you’re either absorbing the SaaS cost, passing it to the client as a line item, or evaluating whether to implement it yourself. None of these options are clean.

At scale: When your MAU count makes per-user auth pricing genuinely painful, or when your authorisation model has grown complex enough that you’re fighting your provider’s data model, that’s when custom auth starts to look rational again. But “at scale” for most Australian SaaS businesses means north of 50,000 MAUs before the economics clearly flip – most products never get there, and the ones that do have engineering capacity to handle the rewrite properly.

What Custom Auth Actually Costs When You Do It Right

If you’re going to build it, build it properly. The shortcuts that feel fast in week one – storing tokens in localStorage, skipping refresh token rotation, not rate-limiting auth endpoints – become security incidents or emergency refactors later.

A production-grade custom auth implementation covering email/password, social OAuth, MFA via TOTP, password reset with secure token expiry, and basic session management runs 80-120 hours of engineering on a mid-complexity stack. Call that $18,000-$30,000 at current Australian agency rates, depending on the stack and whether you’re including admin tooling for user management.

If you add SAML SSO for enterprise clients, budget another 40-60 hours. SAML is not a weekend project. The protocol is byzantine, every identity provider behaves slightly differently, and testing against real enterprise IdPs like Okta and Azure AD takes time you can’t shortcut.

That said, there are scenarios where the investment makes sense from the start:

1. Your product handles sensitive data (health, finance, legal) and you have specific compliance requirements that constrain which third parties can touch your authentication data.
2. You’re building a B2B product with enterprise as the primary go-to-market, and you need SAML from the first client conversation.
3. Your authorisation logic is complex enough that you’d be writing a large custom layer on top of any provider anyway.
4. You’ve already validated the product and you’re in a growth phase where engineering investment in core infrastructure is clearly justified.

The Abstraction Layer That Most Teams Skip

Here’s something we bake into every build we can influence early enough: abstract your auth implementation behind an interface your application code calls, rather than calling your auth provider’s SDK directly throughout the codebase.

It sounds like obvious architecture advice, but it’s genuinely uncommon. Most teams start with Clerk or Auth0, call it directly from their route handlers and API middleware, and six months later switching providers – or moving to custom auth – means touching 40 files across the codebase. We’ve inherited codebases like this. It’s a miserable migration.

If you build a thin service layer that your application talks to – authService.getCurrentUser(), authService.requirePermission() – swapping the underlying implementation becomes a contained problem. It’s maybe a day of additional design work up front and it changes the cost of a future migration from weeks to days.

That’s the kind of decision that doesn’t show up in a demo but matters enormously over the life of a product.

Making the Call

If you’re pre-revenue or early-stage: buy, pick a provider that matches your stack, and abstract it properly from day one. If you’re heading into enterprise conversations within the next six months: talk to someone who’s actually implemented SAML before you sign anything, because the timeline implications are real. If your auth is already causing pain: diagnose whether the problem is the provider or the way you’ve integrated it – they’re different problems with different solutions.

The worst outcome isn’t choosing the wrong provider. It’s treating auth as a solved problem and not making a conscious decision at all. Then it makes the decision for you, usually at the worst possible time.

If you’re about to start a build and want to work through the auth question before a single line of code is written, talk to Amora about your build – it’s exactly the kind of architectural conversation we have before we commit scope.