Why Small Businesses Should Rely on External IDPs — And Why Local Accounts Are Often a Misguided Blocker

I'm working on a side project — not surprising, given that I've got both the skills and the idea. Every developer should have one. Not just for fun, but to keep their skills sharp and learn new things.

Since transitioning to a software development manager, and now Director of Engineering, I’ve moved further away from writing code. That’s not a bad thing — it’s actually a huge advantage. I now have the experience to ensure products are usable, reliable, and built with real-world constraints in mind — like cost and complexity.

Back in the day, when I was in school, I built what I wanted to. Now, I have the experience to make sure I cover my bases — and deliver something that works, scales, and ships.

Authentication: The First (and Often Last) Thing Developers Think About

Your first instinct when building an app? Probably a login form tied to a database. You authenticate a user, and you're done.

Done right? No. Because authentication is just the beginning. You quickly hit the wall with password resets, email changes, confirmation emails, two-factor authentication, and more. For me — especially in this early stage of a project with a shoestring budget — I don’t want to manage email infrastructure. Yes, it’s cheap, but it’s not in the cards yet.

My Recommendation: Forgo Local Accounts — Support Only External IDPs

My go-to advice for developers building applications, especially for small businesses, is this:

Don’t build local user accounts. Instead, support only external Identity Providers (IDPs).

I’ve disabled local sign-in and now only allow login via Microsoft and Google.

Why? Because my application is designed to follow you as a person — your personal identity — and then let you attach your business accounts to it. So you can log in with your personal account, and then link your work or business accounts to the app. That way, your personal use stays free, and your business usage can be billed separately — a win for both user experience and revenue model.

But Wait — What About Account Stickiness?

When I first implemented this, I ran into a real problem: account stickiness.

When a user logs in with a Microsoft or Google account, the IDP (e.g., Google) often reuses the existing session. So if they try to link a second Google account, or a second Microsoft account, the flow fails — it thinks they’re already logged in to that one account, and won’t prompt for a different one.

That’s a huge blocker — especially if your app is meant to support multiple accounts per user.

The Solution: Use prompt=select_account

After some research — and a quick chat with AI — I discovered a simple, powerful parameter:

When included in the authentication flow, this tells the IDP (Google, Microsoft, etc.) to prompt the user to select an account instead of reusing the current one.