We had five OAuth login options on our sign in page.
Google. GitHub. LinkedIn. X. Facebook.
It looked complete. It felt right. More options, more flexibility.
Then one night around 11pm, we were staring at logs trying to figure out why our X integration kept connecting the wrong account.
That is when things got interesting.
What We Build
We are building Made4Founders, a business platform for startup founders.
One of the features is social posting. You connect your X account, write a post in the dashboard, and it publishes for you.
Simple idea. Should be straightforward.
We also let users sign in with X.
At the time, it felt obvious. If we support X, we should support logging in with it too.
What Went Wrong
Here is the problem.
A user signs in using their personal X account. That is the account already active in their browser.
Later, they go to connect their company account for posting.
But X does not give you an account picker. It does not ask which account you want. It just grabs whatever session is active.
So it silently reconnects the personal account.
The user thinks they connected their business account. They write a company update, hit post, and it goes to their personal feed.
Not ideal.
The “Fixes” That Did Not Work
We tried to patch it.
We added a hint telling users to switch accounts on X first.
It did not help.
Even after switching inside X, OAuth still defaulted to the primary session.
The only workaround was telling users to:
- Open an incognito window
- Log into their business account only
- Come back and connect
We actually wrote that into a tooltip.
Then we looked at it and realized how ridiculous that was.
The Question We Should Have Asked Earlier
We stopped debugging and checked our data.
How many users had actually signed up using “Sign in with X”?
Zero.
Not low. Zero.
Every user used Google or email. A few used GitHub or LinkedIn.
Nobody used X.
So we had been maintaining:
- OAuth flows
- Token refresh logic
- API credentials
- Debugging time
For a feature nobody used.
The Fix Took 10 Minutes
We deleted the button.
Removed the frontend component. Cleaned up the API call.
About 20 to 30 lines of code.
Then we separated our X apps:
- One app for login (now disabled)
- One app for posting
Same pattern we already used for LinkedIn.
Immediately, everything worked.
Four login options. No conflicts. Posting works as expected.
What We Actually Learned
This was not really about X.
It was about a common engineering habit.
Adding things because we can, not because they are needed.
Each OAuth provider feels cheap to add.
Just another button. Another callback. Another env variable.
But they are not free.
Each one adds:
- Token flows that can break
- Credentials that expire
- APIs that change
- Edge cases you do not control
And sometimes, they conflict with other features.
The Real Cost of “Just One More Option”
We spent hours debugging X.
- Token issues
- Session conflicts
- API limitations
- OAuth redirect loops
X has also become harder to work with:
- Pay per use pricing
- Limited free tier
- Hidden requirements in the developer console
All of that for a login button nobody clicked.
The Broader Point
Every feature has a maintenance cost.
Not just code.
- Debugging time
- Support tickets
- Mental overhead
- Edge cases
OAuth is especially messy.
Every provider behaves differently:
- Google gives an account picker
- LinkedIn requires separate apps
- Facebook has business requirements
- X uses whatever session is active
There is no standard. Only variations.
Our Rule Now
Before adding a login option, we ask one question:
Would our target user actually sign up this way?
For founders using a business tool:
- Google and email cover almost everything
- GitHub works for technical users
- LinkedIn makes sense
X and Facebook do not.
If the answer is no, we do not add it.
If You Are Building Something Similar
A few things we learned the hard way.
1. Do not mix login and integration OAuth
Session conflicts are real and you cannot control them.
2. Separate your developer apps
Authentication and integrations should not share the same setup.
3. Test with multiple accounts
Most bugs only appear in real world usage patterns.
4. Remove what is not earning its place
It feels wrong, but it is often the right move.
The Result
Four login buttons.
No conflicts.
No late night debugging sessions over something nobody uses.
Sometimes the best feature you can ship is a deletion.
Closing
We are building Made4Founders.
One dashboard to replace a stack of disconnected tools for startup founders.
If you are building in this space, you already know how messy it gets.
We are trying to make it simpler.
Top comments (0)