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

Source: Dev.to

The Plan: Let Users Send Emails From the Platform

Once the backend intelligence layer was working, the next step felt obvious. The imagined flow:

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

On paper, this looked straightforward.

Setting Up Google Cloud

I started by configuring everything in the Google Cloud Console (GCP):

• Created a Google Cloud project.

• Enabled the Gmail API.

• Configured the OAuth consent screen.

• Generated Client ID and Client Secret.

• Added redirect URIs, e.g.:

  http://localhost:3000/api/auth/callback/google

• Added Gmail permissions using scopes such as https://www.googleapis.com/auth/gmail.send.

At this point everything looked correct.

Authentication Worked… But the Token Didn’t

The OAuth redirect succeeded, the client ID was valid, the consent screen displayed, and authentication completed. However, the Gmail provider token never got stored in my database, so:

• No Gmail API calls.
• No email sending.
• No automation.

Thus the feature was effectively useless despite successful authentication.

The 4‑Hour Debugging Spiral

Database Layer

• Database connection.
• User table structure.
• Provider token fields.
• Row‑level security policies.

Everything appeared to be in order.

Server‑Side Logic

• OAuth callback handler.
• Parsing provider tokens.
• Inserting tokens into the database.
• Session handling.

No issues found.

Client‑Side Flow

• Authentication session.
• Provider response.
• Token availability.

Again, nothing stood out.

Google Cloud Configuration

• OAuth scopes.
• Redirect URLs.
• Gmail API permissions.
• Client ID configuration.

All looked fine.

The Realization

After hours of debugging, I asked a simple question: What is the real core of LeadIt?

The answer wasn’t Gmail automation. The core is:

• Discovering companies.
• Analyzing their websites.
• Detecting opportunity signals.
• Generating AI outreach messages.

Automatic email sending is useful, but not essential.

The Founder Decision: Cut the Feature

Instead of sinking more time into OAuth complexity, I removed the email‑automation feature from the MVP. The product now focuses on:

• Company search.
• Website analysis.
• Lead discovery.
• Lead scoring.
• AI‑generated outreach messages.

Users can simply copy the generated message and send it manually.

Simplifying Authentication

I also decided to replace complex OAuth with simple Next.js authentication for the MVP. OAuth brings a lot of moving parts:

• Client IDs.
• Redirect flows.
• Token storage.
• Refresh tokens.
• Permission scopes.

All of which consume development time and debugging effort.

Landing Page Progress

While the backend work continues, I’ve been building the LeadIt landing page, asking myself:

• Does the product idea make sense?
• Is the value proposition clear?
• Would you try a tool like this?

Early feedback has proven invaluable.

What Today Actually Taught Me

• Ship fast.
• Avoid unnecessary complexity.
• Cut features when needed.

Sometimes the smartest engineering decision isn’t fixing a problem—it’s removing the problem entirely.

Final Thought

Building your first SaaS is messy. 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?