Choosing tools you'll actually live with
Picking your MVP's auth (or any layer, really) without thinking is its own kind of overengineering.
Most auth decisions for an MVP aren’t really decisions.
A founder picks up Supabase or Firebase because that’s what the last tutorial used, or because someone on Twitter said it was the obvious choice. The tool gets installed, the project moves on, and nobody thinks too hard about it.
That’s fine, until it isn’t.
The problem with reaching for a BaaS (Backend-as-a-Service) auth layer by default isn’t that these are bad tools. Supabase, Firebase, Clerk, Auth0, etc., they’re genuinely good. The problem is that using them without thinking about fit means you’ll often end up bending the tool to do things it wasn’t designed for. And that bending is the overengineering.
What the decision actually is
Auth for an MVP usually comes down to three shapes:
Roll your own. You own the full implementation: sessions, tokens, password reset flows, the works. The tradeoff is real time spent on infrastructure that has nothing to do with your product. The upside is that you’re forced to think carefully about your data model and your security choices from the start. There’s no “just let the BaaS handle it” to hide behind.
A BaaS auth layer. Supabase, Firebase, Clerk, Auth0, WorkOS. These give you a hosted, managed stack. Auth is one piece of a larger bundle that often includes database, storage, pre-built UI components, and native integration between services. That bundle is real value, especially for budget-constrained teams that don’t want to wire everything together from scratch.
An open source auth library. Something like Better Auth, Lucia, or Auth.js. You own your data model. Providers are abstracted behind an interface. OAuth, magic links, and social login are handled without you reimplementing the underlying protocol. You’re not tied to a particular storage or runtime, so the decision is easy to revisit later.
Our default is the third option: an open source library, social-only login to start, email/password added only when there’s a real reason for it.
Why social-only first
For most MVPs, email/password login is scope creep in disguise. It sounds simple and it isn’t. Password reset flows, email verification, account lockouts, credential storage — none of that is technically hard, but all of it takes time that could go toward the product. And most of the users you’re trying to sign up already have a Google account.
Social login removes signup friction, which matters a lot for consumer apps and most SaaS products targeting technical users. For a pre-revenue project, getting someone through the door in two clicks is worth more than offering them a username and password form.
The cases where you actually need email/password:
- B2B products where enterprise customers won’t use Google or Apple login for compliance or IT policy reasons
- Audiences where social login adoption is low
- Products that need non-email-based identities: handles, anonymous-ish accounts, something that doesn’t anchor to a person’s personal Google account
If you’re not in one of those situations, ship without email/password first. You can add it later. You can’t easily remove a mess you’ve already made.
When BaaS auth earns its place
BaaS auth isn’t the wrong call. It’s the unexamined call that causes problems.
Supabase auth is a strong fit when your product is database-first and you want multi-tenant isolation handled close to the data with minimal setup. The auth, database, and storage come as one coherent bundle. If you need that whole stack, pulling it apart doesn’t make sense.
Firebase auth is worth reaching for when you’re already in the Firebase ecosystem and want auth to plug into the rest of their tooling without extra wiring. It’s a particularly good fit for mobile-first products, and the free tier handles low-traffic launches comfortably.
Clerk makes sense when you need polished sign-in, organization management, invites, and role UIs out of the box, and you don’t want to build them. For B2B products with complex onboarding requirements, it saves real weeks.
Auth0 and WorkOS are the right call when enterprise SSO and compliance certifications are launch requirements, not someday features. You’re paying for that enterprise feature set, but it’s the fastest credible path to “we support SSO.”
The pattern: reach for BaaS auth when its specific strengths match what your product actually needs. That’s a different question than “what’s the default everyone uses.”
What goes wrong when the fit isn’t there
A project we worked on had gone all-in on Supabase auth early which is not a bad call on its face. Supabase is a solid tool and the team knew it. But the product’s auth requirements didn’t quite match what Supabase was designed for. Rather than revisiting the decision, the team kept pushing.
The result: auth concerns leaked into the database layer. Functions and row-level security policies scattered across the codebase, all there to make Supabase behave in ways it wasn’t designed to behave. Not a disaster, but expensive to untangle. The “easy” choice had invited skipping the design thinking that would have prevented the mess.
This is what overengineering actually looks like in practice. It’s not always a team that built something too complex. Sometimes it’s a team that reached for a tool that didn’t fit and then built complexity around the mismatch.
The actual question to ask
Before picking an auth approach, answer two things:
First: do you need BaaS at all? If you’re just reaching for Supabase auth without the database, or using Firebase auth standalone, you’re probably not getting the value that justifies the coupling.
Second: what does your auth actually need to do? Social login is enough for most MVPs. A library handles that cleanly, keeps your data model yours, and leaves the decision easy to revisit. If you have requirements that genuinely fit BaaS (the bundle, the managed infrastructure, the pre-built UI, the free tier), use it.
The goal isn’t to avoid any particular tool. It’s to pick the tool after you’ve thought about what you need, rather than before.
The wider pattern
Auth is a good example because almost every MVP touches it and the decisions calcify early. But the same dynamic shows up across a stack: the database chosen because it’s what the team knew last time, the deployment platform picked because it appeared in a blog post, the third-party service integrated because it was free to start.
Defaults aren’t inherently wrong. Sometimes the popular choice really is the right fit. The risk is when the default gets picked without asking whether it fits at all, and then complexity accumulates to paper over the mismatch.
The question worth asking about any early product decision isn’t “what do most people use?” It’s “what does this product actually need, and what does this tool actually cost us?” Cost meaning time to integrate, coupling to vendor, limits on how the product can evolve. Those questions take ten minutes. The refactoring, later, takes longer.
If you have thoughts on this, we’d like to hear them. And if you’re working through a similar call and want to talk it through, ufe@tcloudlabs.com is the easiest way to reach us.