DEV Community: Kumar Nihal

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

Kumar Nihal — Thu, 19 Mar 2026 14:35:27 +0000

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?

From Architecture to Reality: Building My First SaaS (LeadIt) with AI Outreach and Company Analysis

Kumar Nihal — Sat, 14 Mar 2026 12:21:03 +0000

Two days ago I shared the architecture flow diagram of my SaaS project LeadIt.

Today I want to share what actually happened after that.

Over the last two days, I started turning that architecture into real working modules. Instead of just diagrams and ideas, LeadIt now has actual APIs, a company analysis engine, and an AI-powered outreach generator.

This post is basically a build log of what I implemented and what I learned while building my first SaaS product.

What is LeadIt?

LeadIt is a project I’m building to help with B2B lead discovery and AI-powered outreach.

The idea is simple:

Find companies
Analyze their websites
Detect opportunity signals
Generate personalized outreach emails

Instead of manually researching companies and writing cold emails, the system tries to automate most of that process.

1. Setting Up the Company Search API

The first thing I worked on was the database layer.

I connected my backend with Supabase and verified that I could fetch company records successfully.

Once the connection was stable, I built a Company Search API.

This API supports:

searching companies by company_name
filtering by country
filtering by category
pagination using page, limit, and offset

Pagination was important because once the database grows, returning thousands of records in a single request would slow everything down.

I also made the response lightweight by returning only the required fields instead of full database objects.

After testing the endpoint, it successfully fetched companies like:

Zapier
Freshworks
Postman

Seeing clean API responses was a small but satisfying milestone.

2. Building the Company Analyze Engine

Once companies could be fetched from the database, the next step was analyzing them.

For this, I built what I call the Company Analyze Engine.
The idea is to automatically scan a company website and detect useful signals.
To achieve this, I used Playwright for automated browsing.

The engine visits key pages of a company website:

homepage
careers page
API documentation
integrations page
product pages

To keep the scraper lightweight and fast, I blocked heavy resources like:

images
fonts
CSS

This significantly improves scraping speed.

During analysis, the engine looks for business signals, such as:

hiring activity
availability of APIs
integrations with other tools
automation-related keywords

These signals help determine whether the company might be a good B2B opportunity.

3. Building the Lead Scoring Engine

After detecting signals, I implemented a rule-based lead scoring system.
The goal here is to turn raw signals into a clear opportunity score.

For example:

Companies hiring engineers may be scaling fast
Companies offering APIs may be developer-focused
Companies mentioning automation might be good targets for outreach tools

The system calculates a lead opportunity score and also explains the reason behind the score.

The company endpoint now returns:

detected signals
opportunity score
reasoning behind the score

This module basically acts as the intelligence layer of LeadIt.

4. Building the AI Outreach Generator

Once the system identifies potential opportunities, the next step is outreach.

So I built the AI Outreach Generator.

This module generates personalized cold emails using:

company signals
company context
user skills

For the AI model, I integrated Groq LLM using the llama-3.1-8b-instant model.

To make the emails more effective, I designed three outreach styles:

Observation Style: Point out something interesting about the company.
Opportunity Style: Suggest a possible improvement or opportunity.
Curiosity Style: Spark curiosity to encourage a reply.

The AI response is then parsed into structured output:

email subject
email body

The endpoint now takes company signals and generates context-aware outreach emails automatically.

5. Production Considerations

Even though this is an early version, I tried to keep production stability in mind.

Some safeguards I added include:

input sanitization
prompt injection protection
token limits
timeout protection
rate limiting
concurrency limits

These help prevent abuse and keep the system stable.

6. Debugging Moment: Tailwind CSS Version Conflict

Not everything went smoothly.

While setting up Next.js 14, I kept getting repeated build errors related to Tailwind CSS.
After debugging configs and dependencies, I realized the issue:

I had installed Tailwind CSS v4, which is designed for Next.js 15.
But my project runs on Next.js 14, which caused PostCSS and CSS compilation errors.

The fix was simply downgrading to: Tailwind CSS v3

Once I did that, the build errors disappeared.
A small mistake, but a good reminder about framework compatibility.

Where LeadIt Stands Now

After the last two days of development, LeadIt can now:

search companies from a database
analyze company websites automatically
detect business signals
calculate lead opportunity scores
generate AI-powered outreach emails

This is starting to look like the foundation of an automated B2B lead generation platform.

Still early days, but it’s exciting to see the architecture slowly turn into a real product.

Final Thoughts

Building your first SaaS product is chaotic.

You spend hours debugging small things.
You question your architecture decisions.
You rewrite code multiple times.

But the moment your system actually starts working — APIs responding, AI generating emails, data flowing — it feels incredible.

LeadIt is still early, but the core engine is finally starting to work.

And that feels like real progress.

If you're also building a SaaS or experimenting with AI tools,
I'd love to hear what you're working on.

Building my first AI lead generation SaaS (LeadIt) — MVP architecture

Kumar Nihal — Thu, 12 Mar 2026 09:41:07 +0000

Hi everyone 👋

I'm currently building my first SaaS product called LeadIt.

The idea behind LeadIt is simple:

Quality over quantity in lead generation.

Instead of scraping thousands of random leads, the system tries to identify companies that actually show signals of being a good fit.

This is still an MVP, and I'm trying to keep the architecture simple while validating the idea.

Here is the architecture I designed for the MVP:

Tech Stack

Frontend

Next.js UI

Backend

Next.js server API

Authentication

Google OAuth 2.0

Lead Analysis Modules

Scraper using Playwright
Web intelligence using Tavily API
Signals detection (job listings, API docs, integration pages)
AI-generated outreach emails

AI Layer

Groq for LLM processing

Data Layer

Supabase database

Outreach

Gmail API for sending emails

Workflow

The flow of the system is roughly:

User searches for companies
Scraper collects company data
Signals detection analyzes companies
AI generates personalized outreach emails
Emails are sent and tracked using Gmail API
Data is stored in Supabase

Why I'm building this

I noticed that most lead generation tools focus on volume, not relevance.

The goal of LeadIt is to find high-quality opportunities instead of sending thousands of cold emails.

Feedback welcome 🙏

Since this is still an MVP, I’d love feedback from other builders:

Does this architecture make sense?
Am I overengineering anything?
What would you simplify?

I'm building this in public, so I'll keep sharing progress as I go.

Thanks!