I Spent 4 Hours Debugging Google OAuth… Then I Deleted the Feature (A Lesson While Building My First SaaS)

A few days ago I shared the architecture flow diagram of my SaaS project, LeadIt.

After that, I also shared a post explaining the core backend components I built — things like the company search API, the analysis engine, lead scoring logic, and the AI outreach generator.

Since then I’ve been slowly turning those pieces into an actual working product.

Most of the backend core is now working, and I’ve also been building the landing page that explains the product and its workflow.

But while trying to implement the next feature — email automation using Gmail OAuth — I ran into a problem that ended up teaching me one of the most important lessons about building MVPs.

The Plan: Let Users Send Emails From the Platform

Once the backend intelligence layer was working, the next step felt obvious.
Users should be able to send outreach emails directly from LeadIt.

The flow I imagined was simple.
A user connects their Gmail account → LeadIt generates an AI outreach message → the user can send the email directly from the platform.
To make that work, I needed Google OAuth with Gmail API access.

The expected flow looked something like this:

• User logs in using Google OAuth
• LeadIt asks for permission to access Gmail
• Google returns an access token and refresh token
• Those tokens get stored in my Supabase database
• LeadIt uses the Gmail API to send outreach emails automatically

On paper, this looked straightforward.
But implementing it was a completely different experience.

Setting Up Google Cloud

I started by setting up everything inside Google Cloud Console (GCP).

The usual steps:

• Created a Google Cloud project
• Enabled the Gmail API
• Configured the OAuth consent screen
• Generated Client ID and Client Secret
• Added redirect URIs

Something like this:
http://localhost:3000/api/auth/callback/google

Then I added Gmail permissions using scopes like:
https://www.googleapis.com/auth/gmail.send

At this point everything looked correct.
The configuration seemed fine.
So I moved forward with integrating authentication in the app.

Authentication Worked… But the Token Didn’t

Here’s the weird part.
The Google login itself worked perfectly.
Users could sign in successfully.

That means:

• OAuth redirect worked
• Client ID was valid
• Consent screen worked
• Authentication succeeded

But the Gmail provider token never got stored in my database.
And that token is the most important part.

Without it:

• no Gmail API calls
• no sending emails
• no automation

So even though authentication worked, the feature itself was useless.

The 4-Hour Debugging Spiral

This is where things started getting frustrating. I spent around 3–4 hours debugging the issue. And I checked almost everything I could think of.

Database Layer
First I checked Supabase.
Things I verified:

• database connection
• user table structure
• provider token fields
• row level security policies

Everything looked correct.

Server-Side Logic

Then I checked the backend logic.

Things like:

• OAuth callback handler
• parsing provider tokens
• inserting tokens into the database
• session handling

Still nothing.

Client-Side Flow

Then I checked the frontend flow.

Things like:

• authentication session
• provider response
• token availability

Again… nothing.

Google Cloud Configuration

At this point I went back to Google Cloud.

Checked again:

• OAuth scopes
• redirect URLs
• Gmail API permissions
• client ID configuration

Everything looked fine.
Yet somehow the provider token was never reaching my database.

The Realization

After spending hours debugging this, I finally asked myself a simple question.
Do I actually need this feature right now?
And the honest answer was: No

The real core of LeadIt is not Gmail automation.

The real core is:

• discovering companies
• analyzing their websites
• detecting opportunity signals
• generating AI outreach messages

Sending emails automatically is definitely useful.
But it is not required to validate the product idea.
And that’s when I made a decision.

The Founder Decision: Cut the Feature

Instead of wasting more time on OAuth complexity, I decided to remove the feature from the MVP.
Gmail automation will move to Version 2.
For the MVP, the product will focus only on the core features:

• company search
• website analysis
• lead discovery
• lead scoring
• AI outreach message generation

Instead of automatic email sending, users can simply: copy the generated message and send it manually.

It’s simple.
But for an MVP, simple is actually good.

Simplifying Authentication

While thinking about this, I also made another decision.

Instead of implementing complex OAuth systems right now, I’ll use simple Next.js authentication for the MVP.

OAuth systems bring a lot of complexity:

• client IDs
• redirect flows
• token storage
• refresh tokens
• permission scopes

All of that takes time to build and even more time to debug.
Right now my focus is simple.
Ship the product.

Landing Page Progress

Alongside the backend work, I’ve also been building the LeadIt landing page.
It’s almost complete now.
Soon I’ll share a preview of the landing page and I’d genuinely love feedback from other builders here.
Things like:

• does the product idea make sense?
• is the value proposition clear?
• would you try a tool like this?

Getting early feedback is honestly one of the most useful things when building something from scratch.

What Today Actually Taught Me

At first, today felt like a wasted day.
I didn’t ship the feature I planned.
But in reality, I learned something much more important.
Startups don’t need perfect products.
They need working MVPs.
That means:

• shipping fast
• avoiding unnecessary complexity
• cutting features when needed
• Sometimes the smartest engineering decision isn’t fixing the problem.
• Sometimes it’s removing the problem entirely.

Final Thought

Building your first SaaS is messy.
You’ll spend hours debugging things that might not even matter in the final product.
But every one of those moments teaches you something about building, prioritizing, and shipping faster.
LeadIt is still very early.
But every small step is slowly turning the idea into a real product.
And honestly, that’s the fun part of the journey.

If you're building something right now, I’m curious:
Have you ever spent hours debugging a feature… only to realize you didn’t actually need it?