DEV Community: Karan

I Was Obsessed With Daily Games. So I Made My Own. 🕴️

Karan — Sun, 30 Aug 2026 12:20:32 +0000

Every Day... Without Fail 🎮

Every day, every single day, I play these famous daily mini-games —

like my life depends on it.

I don't know what it is, but I'm just obsessed.

Yet my obsession wasn't complete.

I would finish all of them and still find myself looking for more.

Eventually, I reached the impending conclusion:

"Fine, I'll do it myself."

~ Thanos 😭

And that's how The Bouncer started.

The Hardest Part Wasn't Building It

With how advanced AI development tools have become, actually building an app has become much easier.

You can whip up a website or even a game in minutes with tools like Lovable or Claude Code.

But there's a much bigger question:

Should this thing even exist?

An app can be beautifully designed and technically impressive, but if nobody has a reason to use it, what's the point?

So before touching any code, I spent almost an entire day brainstorming with Claude.

And I knew one thing:

I didn't want to make another generic word game.

It had to be something new. Something simple enough to understand, but interesting enough to keep coming back to.

From Brainstorming to... The Bouncer 🕴️

The original idea was pretty simple.

I was inspired partly by a game called Shopkeeper, which a friend's dad had introduced me to.

The basic concept was:

There is a hidden rule. You don't know what it is. Your job is to figure it out.

That's it.

Well... not quite.

After a lot of back-and-forth with Claude, rejecting ideas that were either too boring or just didn't feel right, we finally got somewhere.

Introducing... The Bouncer 🚪

You are the bouncer.

Six words are waiting outside the club.

Your job? Decide whether each one goes:

IN ✅ or OUT ❌

Some words follow the hidden rule. Some don't.

But you don't know what the rule is.

For example, imagine the hidden rule was:

"Words containing the letter A can come in."

You might see:

APPLE → IN  ✅
TRAIN → IN  ✅
HOUSE → OUT ❌

Now you have to figure out why.

Of course, the real rules are intended to be much more interesting than that 😅

From One Simple Idea to a Full Game 🧠

The original concept was simply: hidden rule → figure it out.

But as I kept thinking about it, the game evolved into something much more structured:

Feature	Details
🔢 Clue words	6 words per puzzle
✅ Words IN	3 words that follow the rule
❌ Words OUT	3 words that don't
👆 Mechanic	Swipe IN or OUT
📊 Stats	Track your performance
📅 Daily	A brand new puzzle every day

The goal wasn't just to make something you could randomly guess your way through.

I wanted the player to actually think.

I Wanted That "OH... I GET IT!" Feeling

I didn't want to make a completely chance-based game.

But I also didn't want to make something so complicated that you needed a PhD to figure out today's rule 😭

Finding that balance is where I think The Bouncer can shine.

I want the player to make calculated guesses, form theories, test them against the words, and slowly narrow down what the rule could be.

One of my favourite games right now is Minute Cryptic, and I wanted The Bouncer to give a somewhat similar feeling.

That progression from:

"What the fuck is this?"

"Wait... it might be this..."

"OH. I'M RIGHT."

...is exactly what I'm aiming for.

Although that last part rarely happens for me 😢🙏

And there's another challenge.

If a daily game takes 15 minutes to solve, people probably aren't coming back every day.

So finding that sweet spot between too easy and way too difficult is going to be one of my biggest challenges.

This Time, I'm Doing It Myself 💪

I thought it was about time that I built something completely by myself.

For almost every other project I've worked on, I've had some sort of assistance along the way — whether from my mentor, my dad, or, of course, AI.

This time, I wanted to take things into my own hands.

And the fact that this game is so closely connected to something I genuinely do every day makes it even more personal.

Building something you actually care about gives you a completely different kind of motivation.

It's one thing to solve a problem because someone told you to.

It's another thing to think:

"I actually want this to exist."

That's the feeling I had with my Gym Scheduler.

And now I'm getting the same feeling with The Bouncer.

Time to Apply What I've Learned 🚀

The tech stack itself was actually quite familiar:

Technology	Role
⚛️ React + Vite	Frontend
🎨 Tailwind CSS	Styling
🍃 MongoDB	Database
🌐 Netlify	Deployment
🤖 Claude	AI assistance

I've worked with most of these before. So this project became a bit of a test:

Can I actually apply everything I've learned so far and build something completely on my own?

There was only one way to find out.

Of Course... I Started With planning.md 📋

Surprise, surprise.

But this time, I tried a slightly different workflow and used pretty much every Claude tool available to me:

Tool	Purpose
🧠 Claude Desktop	Brainstorming
📋 Claude Cowork	planning.md + build.md
🎨 Claude Design	Visual direction
💻 Claude Code	Implementation

Yeah... I know.

I'm extremely Claude-sexual at this point 😭

But honestly, I wanted to see how far I could take an entire project using all the different tools available.

The Idea Was Ready. Now Came the Hard Part.

The concept was locked in.
The design had a direction.
The plan was in place.

Everything looked good on paper.

But here's the thing about games — they only truly exist the moment someone plays them.

And getting from a plan to something actually playable?

That's where things got a lot more...tricky. 😅

See you in Part 2. 🚀

The Little Moments That Made Me Love Programming ❤️

Karan — Sun, 09 Aug 2026 18:48:13 +0000

Hey everyone,

Whenever people ask me,

"How did you get into programming?"

I never really know how to answer.

There wasn't one life-changing moment.
There wasn't one huge project.
There wasn't one magical course.

Instead, it was a collection of lots of tiny moments that slowly made me fall in love with coding.

Looking back now...those little moments still make me smile.

It Started With a Scratch Book 🎮

The biggest reason I got into coding was because of my dad.

He used to work as a software developer before moving into a managerial role, and one day he introduced my brother and me to programming through something surprisingly simple — a Scratch tutorial book.

The book had around ten little games that we had to recreate.

At first, I was simply dragging colorful blocks around the screen.

But slowly...I started understanding the logic behind them.

Seeing a game come alive because of something I built felt magical.
Even better? I could immediately play the game afterwards 😄

I don't think I cared much about programming back then. I just thought,

"This is really fun."

The Python Problem I'll Never Forget 🐍

After Scratch came Python.

My dad started giving my brother and me small programming exercises to solve.

One challenge has stayed with me ever since.

We had to build a simple restaurant program where my dad acted as the customer, and our code became the waiter taking his order.

Everything was going well... until we reached one condition.

The program needed two things to be true before it could continue.

My brother and I kept trying different solutions. Nothing worked.

Then I stopped thinking like a robot for a moment.

"Wait... what if I simply say this AND this has to be true?"

I searched how Python represented an AND condition, changed one line, ran the program...

...and it worked.

Looking back now, it was probably a tiny programming problem.

But I still remember how proud I felt.

It's funny how the smallest victories are sometimes the ones we remember the longest.

One Summer Changed Everything ☀️

The moment coding became more than just little games happened during one summer break in 7th grade.

I enrolled in the Zero to Mastery Complete Web Developer course by Andrei Neagoie.

Every morning after breakfast, my dad would drop me at his second office. I would spend hours there learning before heading home around lunchtime.

Looking back... that summer completely changed how I looked at programming.

The course opened my eyes to an entirely different world.

Not just HTML and CSS. Not just JavaScript.

But React. REST APIs. Backend development. Deployment.

Suddenly, websites weren't magic anymore.

I was slowly learning how they were built.

And that fascinated me.

A Small Confidence Boost 🌟

One thing I'll always remember from that summer was visiting my dad's office.

One of his colleagues used to introduce me to the freshers who had just joined the company.

Honestly... I used to feel a little embarrassed 😅

But somewhere deep down, it also made me feel proud.

For the first time, I quietly thought,

"Yeah... maybe this is what I want to do one day."

That digital world of building things and solving problems suddenly felt like somewhere I belonged.

Every Tiny Project Meant Something 🛠️

From there, I just kept building.

Some of my earliest projects were:

🎮 Stone Paper Scissors
🔤 Palindrome Checker
📝 Shopping List

Looking back today, they're incredibly simple.

But whenever I scroll through those old projects, I don't think,

"Wow... that's bad."

Instead, I smile and think,

"That's where it all started."

Every tiny project taught me something. Every bug taught me patience. Every finished project gave me the confidence to start another one.

Eventually those little projects became:

✨ Quote Generator
💪 Gym Scheduler
🏐 Volleyball Tournament Website
🌍 Open Source Contributions

It's honestly funny to think that I went from dragging colourful Scratch blocks around
➡️➡️➡️
to deploying applications that real people actually use.

Or from figuring out one simple AND condition
➡️➡️➡️
to contributing to open-source projects with thousands of lines of code.

Looking Back... ❤️

A few things stand out more than anything else.

🚀 Consistency Matters

One thing I genuinely regret is taking almost an entire year away from coding during 8th grade.

No projects. No courses. No experimenting. Nothing.

Not because I stopped liking programming.

I just became inconsistent.

Looking back, I don't regret not building something huge.

I regret not building something small.

💡 Small Projects Are Never a Waste of Time

I literally built a Stone Paper Scissors game.

And honestly... I'm still proud of it 😄

It wasn't about how impressive the project was.

It was about showing up, learning something new, and finishing what I started.

Those tiny projects quietly prepared me for the bigger ones.

🤖 Curiosity Will Always Beat Convenience

I've always been very pro-AI, and that hasn't changed.

The things Claude Code and other AI tools can do today still feel like magic sometimes 😅

But one thing has stayed exactly the same.

My curiosity.

Even when AI gives me the answer, I still find myself asking,

"Wait... how did it do that?"

Or, "Could I build this myself?"

For me, AI has never replaced learning.

If anything... it's made me even more curious.

Final Thoughts ❤️

Looking back...

none of these moments felt particularly important while they were happening.

A Scratch game.
A Python exercise.
A summer course.
A tiny portfolio.
A Stone Paper Scissors game.

Individually, they all seemed ordinary.

But somehow those little moments are exactly what made me love programming.

And honestly - I wouldn't trade any of them for anything.

See you guys in the next one. 🚀

The One File That Made Every Project Easier to Build 💡📁

Karan — Sat, 01 Aug 2026 06:34:07 +0000

Hey everyone,

If there's one habit that has improved every project I've built, it isn't React.

It isn't Claude Code.

It isn't AI.

It's spending time planning before writing a single line of code.

My Biggest Mistake 😅

Up until this year, every time I got a new project idea, I would immediately open VS Code and start building.

Always chasing the thrill of seeing an idea come alive as quickly as possible. A bad habit some of us have.

The problem?

Halfway through the project, I would suddenly realize...

"Wtf am I doing?" 😭

Features would keep changing. The structure would become messy. I would rewrite the same files multiple times.

Sometimes I would even abandon the project completely because I hadn't thought things through.

Looking back, I wasn't failing because I couldn't code.

I was failing because I never planned.

The Advice That Changed Everything 💡

One day, my mentor — a senior developer at GoDaddy — gave me a piece of advice that completely changed how I looked at software development.

She said:

"Real coding begins on paper."

At first, I didn't fully understand what she meant.

Sure, I could sketch a few ideas. But what about things like:

Choosing the right tech stack
Planning the architecture
Organizing features
Thinking about edge cases

Questions like:

What happens if the user enters invalid data?
What if the server doesn't respond?
What if I want to add new features later without rewriting everything?

A simple flowchart wasn't enough.

That's when I discovered the power of a planning.md file.

What's Inside My `planning.md`? 📋

The very first thing I do is ask Claude to brainstorm with me instead of jumping straight into coding.

My prompt is usually something along the lines of:

"Let's brainstorm ideas for this project. Ask me plenty of questions, challenge my assumptions, and then create a planning.md file containing the features for Version 1, ideas for Version 2, and a phase-by-phase implementation plan."

From there, the planning file gradually grows into the project's full roadmap.

It usually contains things like:

Project goals
Core features
Future ideas (V2)
Tech stack decisions
Folder structure
Build phases
Edge cases
Things to remember while developing

Why This Actually Helps 🤖

Whether you're using AI tools like Claude Code or planning everything yourself, having a roadmap makes an enormous difference.

If you're using Claude Code — the planning.md file keeps Claude focused on the original vision instead of slowly drifting away as the conversation gets longer.

If you're not using AI — it still acts as your own personal project roadmap. Whenever you come back after a few days, you instantly remember:

What you're building
Why you're building it
What comes next

The planning file also becomes a place where brainstorming never really stops. As new ideas come to mind, they simply get added to the document instead of interrupting development.

Claude is surprisingly helpful here too. It often suggests:

Better alternatives
Cleaner architectures
Features I hadn't considered
Edge cases I completely missed

How It Played Out For Me 🚀

The first project where I fully committed to this workflow was my Gym Scheduler app.

The very first file I created wasn't a React component.

It was planning.md.

As the project grew, so did the planning document. Once Version 1 was complete, I went back and started planning Version 2.

Later, while brainstorming with Claude again, the idea expanded far beyond a simple scheduler. It evolved into a much bigger vision that included:

Feature	Status
AI-powered schedule adjustments	Planned (V2)
Workout tracking	Planned (V2)
Lifestyle and health tools	Planned (V2)
Trainer–trainee booking system	Planned (V2)

None of those ideas interrupted my current work because they already had a place inside the planning file.

Instead of constantly changing the codebase, I was simply expanding the roadmap.

Final Thoughts

The next time you get excited about a new project...

Don't open VS Code first.

Open a blank Markdown file.

Spend 20 to 30 minutes thinking before you start building.

Future you will be very grateful.

See you guys in the next one! 🚀

My Open Source Workflow: How I Went From 1 to 20 Pull Requests 🚀

Karan — Wed, 15 Jul 2026 08:10:11 +0000

Hey guys,

After contributing to my first open-source project, PhysicsHub, I wanted more.

More repositories. More bugs to fix. More contributions.

But it wasn't easy.

Scouring every inch of GitHub just to find one worthwhile issue, then spending several hours creating one pull request... only for it to sometimes get rejected or closed.

That's frustrating.

More importantly, it's highly inefficient.

One thing I've realized is that efficiency matters a lot in coding. I needed some way to make contributing easier and, more importantly, consistent.

"I needed a system."

Building My Open Source Workspace ⚙️

The first thing I did was select a handful of repositories that genuinely interested me.

Then I:

Forked each repository
Cloned my forks locally
Placed everything inside one folder called Open-Source-Contributions

Now I had all my projects in one place.

But I wasn't done yet.

I then used ChatGPT to help me craft a master prompt for Claude Code.

The idea was simple:

Create one central CLAUDE.md containing my personal workflow and rules
Create an individual CLAUDE.md inside each repository so Claude could understand that project's codebase, conventions, and file structure

And... voilà.

My workflow was ready. Ready and efficient 😎

My Daily Routine ☀️

Around every noon, I open my GitHub tab group on Chrome.

It instantly opens every one of my forked repositories.

From there, I simply check the latest issues.

If I find an untouched issue that looks interesting, I dive right in.

I ask Claude to:

🔍 Analyze the issue
🧠 Identify the likely cause
💬 Explain what's happening
🛠️ Suggest a possible fix

Then we solve it together, open a pull request...

...and wham, bam, thank you ma'am 😅

Another contribution done.

Watching those little green squares slowly start flooding my GitHub activity chart is honestly immeasurably satisfying.

How I Pick Repositories 🔍

A few people asked me how I actually find projects worth contributing to.

My first project, PhysicsHub, came from Good First Issue — I talked about that in my previous open-source blog.

But after that, I wanted something bigger.

So I asked Claude to recommend GitHub projects that prioritized three things:

Plenty of beginner-friendly issues
Active maintenance
Responsive maintainers

It generated a list of around 10 repositories.

From there, I filtered them based on:

Filter	Why It Mattered
Projects that genuinely interested me	Keeps motivation high
Tech stack I wanted to improve at	Every PR becomes a learning opportunity

Eventually, I narrowed everything down to these five repositories:

PhysicsHub.io
freeCodeCamp
openlibrary
appwrite
cal.diy

The Result 📈

Having a proper workflow completely changed how I contribute.

Instead of making one or two pull requests whenever I randomly felt motivated...

...I now have around 20 pull requests spread across five different repositories.

The biggest difference wasn't becoming a better programmer overnight.

It was becoming consistent.

Final Thoughts

This workflow didn't just make contributing faster.

It made me actually want to keep contributing.

Before this, the thought of endlessly searching GitHub for a tiny issue was honestly discouraging.

Now:

✅ Everything is organized
✅ Everything is ready
✅ All I have to do is open my workspace and start contributing

Eventually, I'd love to contribute more than just bug fixes — maybe even build entirely new features.

But for now...
I'm enjoying learning one pull request at a time. 🚀

See y'all next time.
Happy learning! 👋

The Biggest Upgrade to My Coding Skills Didn't Come From School 🎓💻

Karan — Fri, 26 Jun 2026 15:34:05 +0000

Hey everyone,

If you've read some of my previous blogs, you'll know that I enjoy building projects — from a Gym Scheduler to contributing to open source.

But here's something that might surprise you.

Almost everything I've used to build those projects wasn't taught to me in school.

In fact, my school barely taught programming at all.

We had the occasional computer class where we'd use things like Microsoft Paint, Excel, or PowerPoint — but I never really got exposed to what software development actually looked like.

If I had only relied on school, I'm honestly not sure I would've discovered how much I enjoy coding.

A Course Changed Everything 🚀

I had always been interested in computers thanks to my dad, who introduced my brother and me to some simple programming challenges when we were younger.

But the point where coding became something I genuinely wanted to pursue was during one summer break in 7th or 8th grade.

That's when I started the Zero to Mastery Complete Web Developer course by Andrei Neagoie.

Looking back, that course completely changed how I viewed programming.

Instead of random topics, everything followed a logical progression:

HTML & CSS
JavaScript
Backend development
APIs & databases
Deployment
Career advice

For the first time, software development felt like one connected journey instead of dozens of unrelated concepts.

Why Structured Courses Worked Better For Me

What I liked most wasn't just the content — it was the structure.

Every module naturally built on the previous one, so I never felt completely lost.

The courses also included:

✅ Hands-on projects
✅ Downloadable resources
✅ Real-world examples
✅ Clear progression from beginner to advanced

There was always a feeling that I was moving forward instead of jumping randomly between tutorials.

The Difference It Made

Later, I also completed a MERN Stack course.

That course introduced me to concepts like CRUD operations, which became the foundation for several of my own projects:

Project	Concepts Used
NGO Management System	CRUD, authentication
Gym Scheduler App	CRUD, user data, scheduling

Those concepts weren't just theory anymore.

I was actually using them to build applications.

Looking back, many of the projects I've written about on this blog probably wouldn't have existed without those courses.

My Advice To Beginners

If you're just starting your programming journey, I'd recommend investing in one well-structured course rather than constantly jumping between random tutorials.

YouTube is an amazing resource — I still use it regularly — but I personally found that structured courses helped me build a much stronger foundation.

The projects, progression, and organization made learning much less overwhelming.

Final Thoughts

I'm definitely not saying courses are the only way to learn programming.

Everyone learns differently.

But for me, they provided the structure that school never did. They gave me:

A roadmap to follow
Concepts I still use today
The confidence to start building my own projects

And honestly...

building projects is where the real learning begins.

See you guys in the next one! 🚀

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. 👀

DEV Community: Karan

I Was Obsessed With Daily Games. So I Made My Own. 🕴️

Every Day... Without Fail 🎮

The Hardest Part Wasn't Building It

From Brainstorming to... The Bouncer 🕴️

Introducing... The Bouncer 🚪

From One Simple Idea to a Full Game 🧠

I Wanted That "OH... I GET IT!" Feeling

This Time, I'm Doing It Myself 💪

Time to Apply What I've Learned 🚀

Of Course... I Started With planning.md 📋

The Idea Was Ready. Now Came the Hard Part.

The Little Moments That Made Me Love Programming ❤️

It Started With a Scratch Book 🎮

The Python Problem I'll Never Forget 🐍

One Summer Changed Everything ☀️

A Small Confidence Boost 🌟

Every Tiny Project Meant Something 🛠️

Looking Back... ❤️

🚀 Consistency Matters

💡 Small Projects Are Never a Waste of Time

🤖 Curiosity Will Always Beat Convenience

Final Thoughts ❤️

The One File That Made Every Project Easier to Build 💡📁

My Biggest Mistake 😅

The Advice That Changed Everything 💡

What's Inside My planning.md? 📋

Why This Actually Helps 🤖

How It Played Out For Me 🚀

Final Thoughts

My Open Source Workflow: How I Went From 1 to 20 Pull Requests 🚀

Building My Open Source Workspace ⚙️

My Daily Routine ☀️

How I Pick Repositories 🔍

The Result 📈

Final Thoughts

The Biggest Upgrade to My Coding Skills Didn't Come From School 🎓💻

A Course Changed Everything 🚀

Why Structured Courses Worked Better For Me

The Difference It Made

My Advice To Beginners

Final Thoughts

Claude Code Broke My App Twice Before Finally Fixing It 😭

The Feature That Started It All 💪

Claude Had a Plan 📋

I Let Claude Run Unsupervised 😭

Everything Broke 💀

Attempt #2 😭

Time To Take Control 🚨

What I Learned 🤔

Feature Showcase 🚀

Final Thoughts

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

Every Project Starts With a Problem

Before Writing Code, We Planned

Claude Became My Project Manager 😅

Building It Phase by Phase

Watching the App Come Alive ✨

The "It Works On My Machine" Moment 😭

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

What's Next?

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

“This Should Take 2 Hours Max” 😅

The UI Looked Incredible 🚀

The Spreadsheet Nightmare 📊😭

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

The Moment Everything Finally Worked ✨

What This Project Taught Me About AI Coding 🤖

Final Thoughts

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

Finding My First Project

Actually Making My First Contribution

What I Fixed

The Best Part

Final Thoughts

🏗️ Still Planning — But This Time It Actually Matters

🔀 The Monolith Decision

📐 SOLID Principles

🤖 How Claude Helped Apply It

🙏 The Mentor Behind All This

What's Inside My `planning.md`? 📋