DEV Community: Karan

Claude Code Broke My App Twice Before Finally Fixing It 😭

Karan — Wed, 17 Jun 2026 06:40:16 +0000

Hey everyone,

To pick up where I left off in my previous post, everything was working smoothly in my Gym Scheduler app.

The login worked. The schedule worked. The deployment worked.

Life was good 😎

Until... I decided to add a new feature.

The Feature That Started It All 💪

I wanted users to be able to create and manage multiple workout programs depending on their goals.

For example:

Push Pull Legs (PPL)
Upper / Lower
Full Body
Strength-Focused Program

Before	After
One simple schedule	Multiple programs users could easily switch between

Simple enough, right?

Yeah... not exactly 😅

Claude Had a Plan 📋

Of course, I turned to Claude.

I started by creating a detailed implementation plan and adding it to my planning.md file.

After reviewing everything, Claude confidently told me:

"Looks good, let's implement it."

Perfect. Everything seemed to be going great.

Claude started:

Creating the necessary files
Installing required packages
Updating the database logic
Writing the code

I was feeling pretty confident.

And then I made my biggest mistake.

I Let Claude Run Unsupervised 😭

The code looked fine. The plan looked fine. Everything seemed fine.

But when I ran the project locally...

everything fell apart.

Everything Broke 💀

Instead of getting a shiny new program-switching feature, I got:

❌ My old schedule disappeared
❌ The styling changed
❌ The dropdown was missing
❌ The feature didn't even exist I just sat there staring at the screen thinking:

"What on earth happened?"

Attempt #2 😭

Naturally, I asked Claude to review the code.

A few moments later:

"Everything looks good 🙂"

And then...

it broke the app again 😭

At this point, I wasn't sure whether to laugh or cry.

Time To Take Control 🚨

I finally decided to stop trusting Claude blindly.

First, I reverted all the changes.

Then I started approaching the problem differently:

Cleared the conversation context
Explained the expected behavior more clearly
Shared screenshots
Updated the implementation plan
Narrowed down what was actually broken

And suddenly, things started making sense.

This time Claude rewrote the affected files differently. The implementation looked cleaner. The logic looked better.

And for the first time...

it actually worked 🎉

What I Learned 🤔

This experience taught me something important.

AI is incredibly powerful.

But when it gets stuck, throwing more prompts at it usually isn't the solution.

What helped was stepping back, understanding the problem myself, and giving better context.

The better I explained the issue, the better Claude's solutions became.

Turns out AI isn't a mind reader after all 😅

Feature Showcase 🚀

After all that debugging, the app ended up much better than before.

Some of the new additions include:

⚖️ BMI Calculator
🔥 Calorie Calculator
📅 Current-Day Highlighting
🔀 Exercise Reordering
🗂️ Multiple Workout Programs
✨ Better UI & UX

Final Thoughts

At the end of the day, the feature did work — despite all the stress it caused 😭

And honestly, the app became much better because of it.

The biggest lesson I took away from this:

AI can write code faster than most developers ever could.
But developers still need to communicate clearly, think critically, and understand what they're building.

The code might be generated by AI.

The direction still comes from you.

Enjoyed this one? Drop a ❤️ and follow along — more parts coming soon! 🚀

I Let Claude Code Build My Gym Scheduler App. Here's What Happened. 🚀

Karan — Thu, 11 Jun 2026 11:17:04 +0000

Every Project Starts With a Problem

As most inventions or ideas begin, mine also started with a problem.

For me, it was in the gym.

I often found myself missing workouts here and there for various reasons — some completely beyond my control. That part is normal. Life happens.

What I struggled with was figuring out how to recover from it.

Most people would simply say:

"If you missed Back Day, just do it tomorrow."

And yes, that works.

But I've always liked having specific workouts on specific days. 'Monday will always be my Chest Day' 😤

That's when an idea hit me.

What if I built a Gym Scheduler that could intelligently reorganize the rest of the week whenever I missed a workout?

The long-term vision is to eventually integrate AI so it can generate personalized workout adjustments based on a user's goals, schedule, and missed sessions.

And since this problem affects me personally, it felt like the perfect project to build.

Before Writing Code, We Planned

One of the most valuable lessons my coding mentor taught me was this:

"Always plan before you build."

A surprising number of development problems can be avoided simply by thinking things through before touching the keyboard.

This became even more important when working with powerful tools like Claude Code.

My initial prompt was something along the lines of:

"I want to build a Gym Scheduler app. Let's brainstorm some ideas first. Ask me lots of questions and create a planning file where we can organize everything."

And that's exactly what happened.

What started as a simple idea quickly became a massive planning document covering:

Architecture
Authentication
Database structure
API routes
Features
Deployment strategy
Build phases

Before a single line of code was written, the entire project had a roadmap.

Honestly, I did not expect the planning file to become this huge 😅

Claude Became My Project Manager 😅

Since I'm still a student developer with a lot left to learn, I didn't want Claude to simply write code for me.

I wanted it to teach me as well.

At several points, I even asked Claude to explain what it was doing and why it was doing it.

One of my goals for this project was to better understand:

Object-Oriented Programming (OOP)
SOLID Principles
Application architecture

Claude suggested the following stack:

Technology	Role
React	Frontend framework
Tailwind CSS	Styling
MongoDB Atlas	Database

But instead of blindly accepting the suggestion, I asked it to justify every choice.

Why React? Why MongoDB? Why not something else?

This ended up being one of the most educational parts of the project — it helped me understand not just what to use, but when to use it.

Building It Phase by Phase

Once the planning was complete, we finally started building.

One thing I specifically asked Claude to do was avoid generating the entire application in one go.

Instead, I wanted it built phase by phase.

This turned out to be one of the best decisions of the entire project.

Benefits for me:

Easier to learn
Easier to understand
Easier to debug

Benefits for Claude:

Smaller tasks
Fewer mistakes
Better code reviews

At one point I even stopped everything just to ask:

"What exactly is a model?"

And instead of throwing code at me, Claude explained the concept and how it fit into the project.

The learning part is always important, no matter how powerful AI becomes.

Watching the App Come Alive ✨

At first, all I could see was a blank page with the floating React-Vite logo.

Not exactly exciting 😭

Then slowly, feature by feature, the app started taking shape:

A login system appeared
Workout schedules started displaying correctly
Exercises could be added and deleted
Pages started connecting together

And suddenly something that had only existed inside a planning document was becoming a real application.

I genuinely couldn't believe how much faster the development process felt compared to some of my earlier projects.

For example, in a previous project, building a simple login system involved:

Watching a 1-hour YouTube tutorial
Reading Firebase documentation
Asking ChatGPT for help
Getting even more errors 😭

This time felt completely different.

Of course... not everything went perfectly.

The "It Works On My Machine" Moment 😭

After finally getting everything working locally, I deployed the application.

And then immediately got hit with this:

Everything worked perfectly on my computer. Production had other plans.

After spending hours investigating the issue, I discovered the problem was hiding inside Google Cloud Console.

My callback URI was only configured for localhost and was missing the deployed Render URL.

A tiny configuration mistake. Several hours of debugging. Classic developer experience 😭

But eventually, after updating the configuration and redeploying, everything finally started working.

The First Version Wasn't Pretty... But It Worked 💪

The first working version looked nothing like the version I use today.

There were no fancy tools, no advanced features, no polished UX, no AI scheduling.

Just the basics:

✅ Add exercises
✅ Delete exercises
✅ Rename workout splits
✅ Store schedules

And honestly? That was enough.

Because it worked.

For the first time, I had a functional application solving a real problem that I personally faced.

And that felt amazing.

What's Next?

The first version was functional — but it was also very rough.

In Part 2, I'll talk about how I transformed it from a simple scheduler into something much more polished by adding:

Multiple programs
Exercise reordering
Current-day highlighting
BMI Calculator
Calorie Calculator
Better UI/UX
And some fun gym-specific touches 😎

Unfortunately... waiting for me was the most frustrating bug of the entire project so far 😭🙏

See y'all in the next one 🚀

We Built a Real Volleyball Tournament Website Almost Entirely With AI 🏐🤖

Karan — Thu, 21 May 2026 09:35:02 +0000

Hey guys,

Recently in my society, I attended an AI seminar session.
At first, it honestly did not seem that useful 😅

It was mostly:

general knowledge about AI chatbots
the history of AI
a few cool examples

…but nothing that really stood out to me and my friend.

Until the host casually mentioned something interesting:
“Even students can now build and deploy apps using AI… and maybe even earn money from them.”

Now THAT got us thinking 👀

And somehow, within the next few minutes, we came up with the idea of building a volleyball tournament scoring and tracking website for our society tournament.

The more we discussed it, the bigger the idea became:

Live standings
Match schedules
Team tracking
Admin dashboard
Live score updates

And somehow it slowly became a competition between me and my friend to see who could build the better app 😭

A healthy competition, of course.

“This Should Take 2 Hours Max” 😅

We genuinely thought this would be super easy.

Our original plan was basically:

Ask ChatGPT to generate a prompt
Paste it into some AI app builder
Add a few finishing touches
Become millionaire startup founders overnight ✨

Simple, right?

Yeah… not exactly.
I started by asking ChatGPT to create a detailed master prompt for the app.
It asked me everything:

app purpose
functionality
design preferences
tech stack
features
backend requirements

And then it suggested using:

v0 by Vercel for generating the app
Supabase for the backend

So I copied the generated prompt into v0…
…and within 5 minutes…
BOOM 💥

The app preview was ready.

The UI Looked Incredible 🚀

Honestly, the UI looked WAY better than I expected.

It had:

smooth transitions
clean dashboards
a modern tech-style design
beautifully designed standings cards
proper page linking

Everything looked polished.

So polished, in fact, that I genuinely wanted to deploy it before the backend even existed 😭

I sat there admiring the preview for a while…
…and then reality hit.
Almost nothing actually worked.💀

I thought:
“No problem. Once I connect the backend, everything should work.”

Yeah… no

The Spreadsheet Nightmare 📊😭

The backend part of the project was honestly chaos.

The existing tournament spreadsheets were:

poorly labeled
inconsistent
randomly formatted
confusing to read

Human-made spreadsheets are terrifying sometimes 😭
But when in doubt…
Get the Claude out.

I used Claude Desktop and uploaded all the existing:

score sheets
team lists
schedules
tournament data

Then I asked it to reorganize everything properly into structured Excel files that could directly fit into my Supabase tables.

And somehow…
…it actually worked REALLY well.

After a little back and forth, the data was finally clean enough to import into the database.

Honestly, AI saved me HOURS here.

“Fixed the Issue” …Except It Didn’t 😭

At this point, I thought:
“Okay, database is ready. Surely the app works now.”
Nope.

The admin dashboard was completely broken 😅 Buttons existed.
They looked functional. They even had hover effects.
But clicking them did absolutely nothing 💀

Classic AI-generated functionality.

So I connected the project to:

GitHub
Vercel

Then I cloned the repo locally and brought in my most trusted debugging partner:
Claude Code.

And honestly, even Claude struggled a bit here 😭

It kept:

“fixing” the issue
correcting itself
generating new fixes
making me push code changes

…only for absolutely nothing to happen.

At one point it genuinely became:

“Trust me bro, this fix will work.” 😭

Eventually, I realized I needed to provide WAY more context and explain the issue more clearly instead of expecting AI to magically understand everything.

After narrowing things down properly…
…it turned out to be a package issue all along.🥲🙏

The Moment Everything Finally Worked ✨

After fixing the package issue, I pushed the changes to GitHub.

And within a minute…

everything started working.

It genuinely felt like a miracle 😭

The standings updated correctly.
The right teams had the right points.
The fixtures displayed properly.
The schedules synced correctly.

Everything was LIVE.

And the best part?

People actually started using it during the tournament 🏐

I shared the website in our volleyball group and received a lot of positive feedback, which honestly felt amazing.

At that moment, it felt like:
“Wait… I actually built something REAL.”

Meanwhile my friend, who was building his version on Lovable, could only get basic scoring functionality working 😎💪

So technically…
…I win.

This should probably be your climax image section.

What This Project Taught Me About AI Coding 🤖

This project completely changed how I look at AI-assisted development.
AI is genuinely an insanely powerful time-saving tool.
But…

AI only saves time if the developer knows how to guide it properly.

Things like:

debugging knowledge
context sharing
proper prompting
understanding systems
identifying errors

…still matter A LOT.

Because the truth is:

AI can generate code quickly. But building a usable real-world app still requires developer thinking.
And honestly, I think that’s the most exciting part.

AI is not replacing developers.
It’s making developers faster 🚀

Final Thoughts

This project started as:

“Let’s see if AI can build us a cool website.”

But it ended up teaching me:

backend integration
debugging
deployment
database management
AI prompting
and how important developer guidance still is

And somehow…
what started as a random society seminar idea became a fully deployed tournament website people actually used 😅

Definitely one of the coolest projects I’ve worked on so far.

See you guys in the next one 🚀

I Searched for Internships… and Ended Up Contributing to Open Source Instead 🚀

Karan — Thu, 14 May 2026 08:47:53 +0000

Hey everyone,

These last few weeks of my summer break made me realize that I should probably try finding and completing an internship — even if it was just for 2 weeks.

But while searching around and talking with Claude about internships, it suggested something even better:

🙌Contributing to open-source projects.🙌

Now, I know many developers reading this probably discovered open source years ago 😅
But for me, this was something completely new and honestly really exciting.

Finding My First Project

I started digging deeper into this whole open-source world and quickly realized there are actually some really beginner-friendly websites to get started.

These were the two websites Claude suggested to me:

And that’s when I found:

PhysicsHub

It’s a really neat web app that helps students study physics using interactive simulations and visualizations.

As a physics student myself, this honestly felt like the perfect project to contribute to:

I could improve my coding skills
understand some physics concepts visually
and contribute something useful at the same time

Actually Making My First Contribution

I knew this project wasn’t some massive large-scale application or anything like that.

But honestly, that’s the whole point.

You can’t start huge immediately.

Every small contribution matters.

So I got started:

Forked the repository
Cloned it locally
Opened it in VS Code
Installed Claude Code
Started identifying issues

And this part genuinely surprised me.

I simply asked Claude to help me make my first contribution.

Within seconds, it generated a CLAUDE_REPORT file that contained:

bugs ranked by priority
difficulty levels
possible causes
and even suggested fixes

Claude continues to amaze me yet again 😍😅

I started tackling some low-priority issues one by one and managed to fix 4 issues within my first hour before sending my first pull request.

What I Fixed

The issues themselves were small, but they were actual real-world fixes:

Incorrect labels
Flexible package versions
Unit fixes
Mathematical calculation corrections

Nothing revolutionary 😅
But that’s exactly what made this experience feel approachable for me.

The Best Part

The satisfaction you get from:

adding changed files
committing them
pushing your changes
opening a pull request
and then seeing it get merged

…it’s honestly hard to describe.

And of course, who can forget the beautiful green contribution boxes on GitHub 😅

Seeing those slowly appear somehow makes everything feel more real.

Final Thoughts

I’ll definitely continue contributing to more open-source projects now — especially after realizing how enjoyable and beginner-friendly it can actually be.

I mainly wanted to document my first step into the open-source world and hopefully help other beginners realize that contributions do not have to be huge to matter.

Sometimes even small fixes are enough to get started.

And honestly… starting is probably the hardest part.

You’ll definitely be hearing more from me about open-source contributions — especially when I find another fun project to work on 🚀

See you guys!

🏗️ Still Planning — But This Time It Actually Matters

Karan — Tue, 14 Apr 2026 10:23:49 +0000

Hey guys,

Still stuck in planning mode 😅. But these decisions may be more worthwhile than they seem.

🔀 The Monolith Decision

Monolithic architecture is simply a software development model where the entire app lives in a single codebase. Pretty much the traditional setup most beginner developers follow naturally without even realising it.

Microservices on the other hand is a distributed architecture where several individual services connect and communicate with each other to function as one application. Scalability is the main reason why microservices is so widely adopted — companies like Netflix, Amazon, Uber and Spotify all run on it. Imagine Netflix operating on a single server and a single codebase. Debugging would be a nightmare, maintenance would be chaos, and one bad bug could potentially take down the entire platform for millions of users. Not ideal. 😬

For me though, the choice was obvious — monolith. No plans to massively scale this app, a single codebase keeps things simple, and it's cost-effective.

Sometimes the boring choice is the right one.

📐 SOLID Principles

A great man named Robert C. Martin created the SOLID principles — giving us developers yet another thing to study😒. Just kidding, it's genuinely useful.

In short, following SOLID makes your code:

Maintainable — easier to update and refactor
Scalable — grows with fewer issues
Reusable — modular and decoupled
Readable — cleaner and easier to understand

There are 5 principles in total — S, O, L, I, D. I studied all five. I applied two.

And that was intentional.

Since my app is small with minimal business logic, forcing all 5 would just be over-engineering for the sake of it. Good principles applied in the wrong context are still bad decisions.

🤖 How Claude Helped Apply It

Once I studied the principles, I asked Claude Code to analyse my project and apply
SOLID to the planning. What it did was clean and practical.

For Single Responsibility (S), it wasn't just about separating files — it also
meant breaking down logic into focused modular functions rather than having one
function trying to do three things at once. Models only hold Mongoose schemas.
Routes only handle HTTP. Middleware only handles authentication. Nothing overlaps.

For Interface Segregation (I), it split the API folder by domain —
scheduleApi.js and authApi.js became separate concerns — so different parts
of the app only import what they actually need, rather than pulling from one
bloated module that knows too much.

For O, L and D — Claude explicitly flagged these as unnecessary for this project. The business logic is too minimal to justify them. The philosophy was
simple — use SOLID where it helps, skip it where it doesn't.

🙏 The Mentor Behind All This

None of this planning rigour came from nowhere. I have been fortunate enough to
have a mentor — a senior professional at GoDaddy — who has been guiding me
through these concepts completely voluntarily. Having someone with real industry
experience push you to think about architecture and principles before touching
code is something most student developers don't get. Genuinely grateful for it. ✨

👀 What's Next

OOP is on the study list — the 4 pillars, how they connect to this project,
and then finally, actually building something.

The planning era is almost over. See you on the other side. 🚀

Before Writing a Single Line of Code — Planning My Gym App🏋️

Karan — Sat, 28 Mar 2026 06:27:01 +0000

Hey fellow devs, 👋

Moving on from AI chaos, this time it's all about learning something new.

💡 What I'm Building

I'm building a simple gym schedule app — entirely with the help of Claude.

The app lets users set a weekly schedule from Monday to Sunday, with their gym
timings, workout split, exercises, reps and sets. Nothing fancy — this is purely
a practice project. But the plan is to build it right, not just fast.

Since vibe coding is clearly the future, getting comfortable with it early felt
like a smart move. 🚀

📊 Sequence Diagrams — What Even Are They?

A sequence diagram maps out how different parts of a system interact with each
other in a specific order over time.

Think of it like a WhatsApp conversation — you can see exactly who said what, to whom, and in what order.

Here's the sequence diagram I made for my app:

🧠 How I Actually Built It

The first step is identifying your actors — the objects that interact with
the system. For my app this was straightforward:

The User — inputs the schedule
The UI — handles what the user sees and does
The Database — saves and retrieves the data

Simple enough. But here's where it gets interesting.

Good developers don't just map out the ideal scenario. They think about
everything that could go wrong. Because it's an imperfect world.

For example — what happens if the user tries to save a workout day without
filling in all the fields? No exercises, no reps, just an empty entry hitting
the database. The diagram needs to account for that validation step, otherwise
that's a bug waiting to happen from day one.

Thinking about failure early is what separates planned apps from messy ones.

🗺️ Why Planning Actually Matters

Jumping straight into code is tempting. I get it.

But mapping the flow first forces you to ask questions you'd otherwise miss —
Is this feature actually necessary? What happens if this step fails? Does this
even make sense?

In a small project like this it keeps things clean. In larger projects, it can
save weeks of rework. The planning stage is unglamorous but it's genuinely
important.

🤖 Claude's Role — Plan Mode

Claude is brilliant at building apps, but even Claude isn't perfect — and
usually when something goes wrong, it's because the prompt wasn't clear enough.
That's on the user, not Claude.

So before touching any code, I sent Claude my sequence diagram and we
brainstormed the entire app structure together in plan mode — no building,
just thinking. Getting Claude to deeply understand what I want before it starts
writing anything makes the whole process cleaner and faster.

Context first, code later. ✨

Next up — enough planning, time to actually build something. See you there. 👀

🤖 Adding AI to My Project Wasn't Easy. Until It Was.😅

Karan — Fri, 20 Mar 2026 08:44:14 +0000

Hey fellow developers, 👋

My hyped up hopes and dreams of adding AI magic to my project did not go as planned.🥲 Reality often hurts.

🔍 First Attempt — HuggingFace

I asked ChatGPT for free AI model options and landed on HuggingFace — free, easy to set up, seemed perfect. Got the API key, set the environment variables, wrote the post route, and sat back to enjoy the fruits of my labour.

The model loaded… and then just returned garbage. Incomplete sentences, broken outputs, nothing close to an actual quote. Turns out the model I picked wasn't built for clean text generation from short prompts.

Wrong tool, wrong job. Classic. 🙃

😤 Second Attempt — OpenAI

So I switched to OpenAI with my head held high, because that's what optimistic developers do.

Same process — new keys, new route, new hope. This time I got hit with billing issues and quota errors before I even got started. 404s everywhere. I didn't fully understand what was happening and honestly? I didn't want to. I just moved on.

Then came my board exams and the project sat untouched for a while.

🚀 Enter Claude — The SAVIOUR🙌

When I came back, Claude was everywhere. My dad got the subscription, I took Anthropic's Claude 101 course, and I finally tried Claude Code.

Best decision I've made in this entire project.

I explained my project in plain English — what it does, what I want, what's broken. It analysed everything, suggested Gemini Flash 2.5 as the model, and within minutes had:

Built the API route
Added proper error handling
Updated the frontend elements

All I had to do was paste the API key and watch. 👀

🐛 Minor Setbacks (Because Nothing Ever Works First Try)

Did everything work perfectly on the first run? No. Obviously not. 😂

Because no code ever works on the first try — and every developer has used the infamous "it should work now" line at least a hundred times. I am no different.

But whenever something broke, I'd screenshot the console error, show it to Claude, and it would fix it almost immediately. Within about an hour — a working AI quote generator.

✨ What I Actually Learned

Being a developer today isn't just about writing code. It's about knowing which tools exist, being willing to switch when something isn't working, and not being too proud to ask for help.

Two months ago I'd never heard of Claude Code. Now it's a core part of how I build.

Change is inevitable. Ride along with it.

My live project here👇
https://techgenius-karan.github.io/Random-quote-generator-upgraded/

Next up — I'm not done hyping Claude just yet. More on how it levelled up this entire project in my next post. 👀

🚀 Deploying My Full-Stack App: From Localhost to Live

Karan — Wed, 31 Dec 2025 04:53:25 +0000

Hey everyone! 👋
Picking up right from where we left off — both the frontend and backend of my project were working beautifully on my local system.
All that was left was to deploy everything to the real world… where the real magic (and bugs 😅) happen.

🌐 Deployment Setup

Frontend (GitHub Pages)
I took the straightforward route and deployed my frontend using GitHub Pages. The process was smooth, and the site was up and running almost instantly. No major issues here since it was a static frontend.

The real challenge? The backend.

☁️ Backend Deployment (Render)

I used Render to deploy my backend because:

It’s beginner-friendly
Free to use
I had prior experience with it

Initially, my backend was connected to local MongoDB (Compass).
Once deployed, everything stopped working.

🐛 The Problem (Symptoms)

Clicking Generate did absolutely nothing:

No new quote
No background change
No errors on the UI

That meant one thing:

quotes was empty, so newQuote() exited immediately.

if (quotes.length === 0) return;

So the real question became:

Why was fetchQuotes() no longer populating data?

🔍 Debugging the Issue

Here’s the logic trail I followed:

Frontend now points to Render backend
Render backend CANNOT access local MongoDB (the part I had missed)
API returns an empty response
Frontend correctly refuses to render empty data

So technically… nothing was “broken”.
The system was doing exactly what it was told to do.

✅ The Real Fix: MongoDB Atlas

The solution was to move from local MongoDB to a cloud-based database. I:

Set up MongoDB Atlas
Created a new cluster
Seeded the database with sample quotes
Connected Atlas to Render using environment variables

MONGO_URI = mongodb+srv://quoteAdmin:YOUR_PASSWORD@.../quoteGeneratorDB PORT = 5000
Then I updated the frontend API_URL:

let API_URL = "http://localhost:5000";

⬇️⬇️⬇️

let API_URL = "https://YOUR-RENDER-URL.onrender.com";

🐛 Debugging (The Second Heartbreak💔)

After connecting MongoDB Atlas, Render, and updating all the environment variables, I was confident everything should work.

But… clicking Generate still did nothing.
Same symptom. Same silence. Honestly, it was heartbreaking.

At this point, I had no idea what was wrong because everything was technically correct.

To dig deeper, I directly visited my API endpoint in the browser:
https://quote-generator-5qei.onrender.com/quotes

I saw the words Cannot GET and assumed it was an error and something was wrong with my code, but after repeatedly checking my console and recieving no errors -
That’s when it finally clicked.

There was nothing wrong with my code, deployment, or API.
I had simply forgotten to seed data into MongoDB Atlas. All my quotes were still sitting in my local database.

A painful but valuable lesson:

Sometimes, the bug isn’t in the code — it’s in the data.

🎉 Final Result

And… voilà! 🎉
Once the database was seeded with sample quotes and connected properly:

Quotes started loading
Generate button worked
Categories functioned perfectly
Full-stack data flow was live

This felt like the moment the project officially became real.

🔮 What’s Coming Next

Next up:

🧠 AI integration ideas (brief planning)
✨ Generating original quotes
🎯 Personalization & scalability

See you in the next post — stay tuned! 🚀

🧠 Going Full Stack: Building the Backend & REST API

Karan — Fri, 26 Dec 2025 08:26:42 +0000

Hey fellow developers! 👋

In my last post, I mainly focused on upgrading the frontend UI and UX. While it looked much better, it still lacked the full-stack feel of a real application.
So this post is all about the backend — where things actually started getting serious.

❓ Why Adding a Backend Was Necessary

Initially, I wanted to add a backend to practice and improve my backend skills. But from the app’s perspective, a backend was essential for:

📚 Large amounts of quote data
🤖 Future AI scalability
🗂️ Category-based filtering

Handling all of this purely on the frontend would’ve been messy and unrealistic.
With a backend? Clean and manageable.

⚙️ Backend Setup & Structure

I used a simple and efficient stack:

Node.js + Express → REST API
MongoDB (Compass locally) → Database
Render → Backend deployment (more on this next post 👀)

📁 Project Structure
/
├── index.html
├── style.css
├── script.js
├── backend/
│ ├── server.js
│ └── models/
│ └── Quote.js
└── README.md

🧩 Schema Creation

At the core of the backend was the quote schema:

const quoteSchema = new mongoose.Schema({
  text: { type: String, required: true },
  author: { type: String, required: true },
  category: { type: String, required: true }
});

This schema made everything possible.

Here’s how it works:

A category button is clicked on the frontend
A request is sent to the backend
The backend filters quotes by category
The text + author are sent back
The quote is displayed to the user

This is where the magic of schemas really clicked for me ✨

🔗 Connecting Backend to Frontend

Once the backend was ready, it was time to connect everything.

Inside index.js, I created a fetchQuotes() function:

async function fetchQuotes(category = null) {
  try {
    let url = category
      ? `${API_URL}/quotes/category/${category}`
      : `${API_URL}/quotes`;

    const res = await fetch(url);
    quotes = await res.json();

    usedQuotes = [];
    usedColours = [];
    newQuote();
  } catch (err) {
    console.error("Backend not available:", err);
  }
}

fetchQuotes();

For now, API_URL points to localhost.
Later, this will switch to a deployed backend URL — which leads perfectly into the next post 👇

✅ Final Result (Locally)

And… voila! 🎉
Everything was working perfectly on my local system:

Quotes fetched from the backend
Categories filtered correctly
No more hardcoded data

All that was left was deployment.

🚀 What’s Coming Next

In the next post, I’ll cover:

🌐 Frontend deployment → GitHub Pages
☁️ Backend deployment → Render
🧪 Live-data debugging
🔄 MongoDB Compass → MongoDB Atlas

Be stoked for the next update — see you soon! 😄🔥

Improving the UI & UX of My Quote Generator✨🎨

Karan — Sat, 20 Dec 2025 12:03:14 +0000

Improving the Frontend: UI & UX

Hey everyone!,
This is the second post in my quote generator project series. In this one, I’ll talk about why and how I updated the UI and UX on the frontend to make the project feel more appealing and realistic.

Why I Had to Change the UI

Personally, an unnatural and featureless UI completely repels me.
And honestly, you DO judge a book by its cover — I definitely do. I didn’t want my project’s “cover” to be something that makes people close the tab instantly.

That said, functionality matters too. So instead of focusing only on looks or only on logic, I decided to pair both together.

The goal was simple:

Make the app enjoyable to use and realistic enough to feel like a real product.

What I Decided to Improve

I started adding simple CSS styles and logical frontend features — nothing too crazy, but enough to make the project feel alive.

Here’s what I added:

Dark / Light Mode
Dynamic Backgrounds
Smooth Animations
Better layout
Copy Quote Button
Category-Based Quotes

🔁 Dark / Light Mode: The Toggle Logic

One of the most important pieces of logic I worked on was the dark/light mode toggle.
It’s a small feature, but it completely changes how the app feels.

Here’s the JavaScript behind it:

function toggleMode() {
  darkMode = !darkMode;
  document.body.classList.toggle("dark-mode");

  let btn = document.getElementById("modeToggle");
  btn.classList.toggle("active");
  let ball = document.querySelector(".toggle-ball");

  ball.textContent = darkMode ? "🌞" : "🌙";

  document.body.style.backgroundColor = darkMode ? "#121212" : "#49B587";
}

The logic is simple:

Toggle a dark-mode class on the body
Update the button state
Switch icons (🌞 / 🌙)
Dynamically change background colors

Nothing too complex — but very effective.

🌗 Before vs After: Toggle in Action

Visually, this made a huge difference.

Light Mode (Before):

Dark Mode (After):

This single feature alone made the app feel far more modern and usable.

🎯 What I Took Away From This

Working on this frontend taught me a lot about the ins and outs of CSS — layouts, animations, theming, and how small UI details can completely change user experience.

These are skills that I know will come in handy in pretty much any future project I work on.

In the next post, I’ll move away from UI and dive into the backend side of this project — APIs, databases, and making this app truly full stack.

Stay tuned!🚀

A Simple Project That Turned Into Something Much More!

Karan — Thu, 18 Dec 2025 07:59:12 +0000

Hey everyone!
I’m back after a while — mainly because of preboard examinations. During this short break, I wanted to build a small mini project just to refresh my programming skills a bit. But somehow, that “small project” turned into something much bigger than I had planned.

The Original Project (30 Minutes, Max)

The original project was a simple combination of HTML, CSS, and JavaScript. Nothing fancy at all.
It was a basic quote generator — a text area and a button. On clicking the button, it would randomly display quotes that I had (very honestly) copied from Google and stored inside a JavaScript array.

I added some CSS for structure and background styling. I also tried a few button tricks that didn’t really work out, but at that point, I didn’t care much. It was just a quick, silly project — and let’s be real, a quote generator is not exactly a billion-dollar idea.

Still, it worked. And for a 30-minute project, that felt good enough.

(I’ll link the original live version here 👇)
👉 Original 30-minute Quote Generator

Why It Felt… Incomplete

After a while, I started feeling that this project was pretty dumb in its current state. It did the job, but that was it. So instead of looking for a brand-new project to improve my full-stack skills, I asked myself:
Why not just improve what’s already in front of me?

This version was missing a lot:

No backend
No data storage
No uniqueness
Very limited scope
Zero “real-world” feel

The Idea to Rebuild It Properly

Like most of us, I went to ChatGPT hoping for some magical ideas. It didn’t really give me anything groundbreaking — but it did get me thinking.

That’s when I came up with my own ideas:

Adding a backend with a REST API
Storing quotes properly using a database
Improving the UI and UX (because if it looks boring, I stop working on it)
Eventually integrating AI to generate original quotes based on user mood or preferences

At that point, this was no longer a 30-minute project.

What This Series Is About

This post is essentially about showing the impact of time:

a quick 30-minute frontend-only project
VS
a 3 week full-stack, feature-rich, AI-ready application**

This will be a multi-part series where I document how I upgraded this project step by step — from UI improvements to backend development and beyond.

So yeah, buckle up! Some interesting updates are coming soon!! 🚀

OAuth, Firebase & Some ChatGPT Magic🎉

Karan — Thu, 22 May 2025 08:04:40 +0000

Hey guys! I'm back with another update on my progress with the app I've been building.

After spending a good amount of time learning and absorbing all kinds of new concepts (OAuth, RBAC, Auth Context, etc.), this week was all about putting that knowledge into action.

🔨 Time to Build

My goal? Set up a working login and signup system with OAuth providers like Google and Apple — you know, those buttons that say “Sign in with Google” or “Continue with Apple”.

I followed this great Firebase Authentication Crash Course on YouTube, and it really helped me understand how to use Firebase to manage users.

🤯 The Smart Shortcut

At first, I was going to do a complete code-along, but halfway through, I had a better idea…

Instead of copying code line-by-line and pausing constantly, I asked ChatGPT to analyze the video, extract the code, and explain the steps I needed to follow. And honestly? It saved me hours.

I got the full code setup — Auth Context files, Firebase integration, and even styling — in under 10 seconds.

🛠 Debugging & Finishing Touches

Of course, the code didn’t work right away (does it ever?). I ran into a bunch of errors, but I used ChatGPT again to help me understand what they meant and how to fix them.

One by one, I squashed the bugs, and finally, my beautiful login screen came back to life. 🎉

Now, users can:

Sign up with email and password
Log in
Use “Forgot Password”
Sign in with Google (OAuth)

All of it works perfectly and updates the Firebase console. Super satisfying.

🧠 What's Next?

I’m currently prepping for the SATs, so updates might slow down a bit — but I’m still building, and I’ll be back with more progress soon!

See you guys!(hopefully soon)