<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" 
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Nabil Thange - Blog</title>
    <link>https://nabil-thange.vercel.app/blog</link>
    <description>Full-stack developer and AI engineer from Mumbai, India. Sharing insights on web development, AI integration, hackathons, and building products that matter.</description>
    <language>en-IN</language>
    <lastBuildDate>Sun, 01 Dec 2024 00:00:00 GMT</lastBuildDate>
    <pubDate>Fri, 03 Apr 2026 19:35:34 GMT</pubDate>
    <ttl>3600</ttl>
    <atom:link href="https://nabil-thange.vercel.app/feed.xml" rel="self" type="application/rss+xml"/>
    <managingEditor>thangenabil@gmail.com (Nabil Salim Thange)</managingEditor>
    <webMaster>thangenabil@gmail.com (Nabil Salim Thange)</webMaster>
    <copyright>Copyright 2026 Nabil Salim Thange. All rights reserved.</copyright>
    <image>
      <url>https://nabil-thange.vercel.app/og-image.png</url>
      <title>Nabil Thange</title>
      <link>https://nabil-thange.vercel.app</link>
      <width>144</width>
      <height>144</height>
    </image>
    
    <item>
      <title>Building AI That Doesn&apos;t Suck</title>
      <link>https://nabil-thange.vercel.app/blog/building-ai-that-doesnt-suck</link>
      <guid isPermaLink="true">https://nabil-thange.vercel.app/blog/building-ai-that-doesnt-suck</guid>
      <description>Most AI applications feel like tech demos. I explore what it takes to build AI-powered tools that people actually want to use daily.</description>
      <content:encoded><![CDATA[
# Building AI That Doesn't Suck

Most AI applications today feel like tech demos. They showcase impressive capabilities but fail at the most basic requirement: **making users want to come back tomorrow**.

## The Problem with AI Products Today

After building NbAIl (our HackHazards 2025 winning AI assistant) and experimenting with various AI tools, I've noticed a consistent pattern: **most AI products prioritize technical achievement over user experience**.

### What Makes AI Products Suck

1. **Over-engineering**: Too many features, not enough focus
2. **Poor UX**: Complex interfaces that require a manual
3. **Unreliable outputs**: Great 80% of the time, unusable 20% of the time
4. **No clear use case**: Cool tech looking for a problem

## Lessons from Building NbAIl

When we built NbAIl, we focused on three core principles:

### 1. Solve One Problem Really Well

Instead of building a general-purpose AI assistant, we focused on **desktop automation with voice control**. This narrow focus allowed us to nail the user experience.

### 2. Make It Feel Natural

We integrated Three.js for visual feedback and Groq for ultra-fast responses. The goal wasn't just to process commands—it was to make the interaction feel **conversational and human**.

### 3. Handle Failure Gracefully

AI will fail. Accept it. Build systems that degrade gracefully and give users clear feedback when things go wrong.

## The Secret: Start with the User, Not the Model

Here's the controversial take: **your AI model doesn't matter if your product sucks**.

Users don't care about:
- Your model's parameter count
- Which LLM you're using
- Your fine-tuning approach

They care about:
- Can it solve my problem?
- Is it fast?
- Does it work reliably?

## Building AI That Doesn't Suck: A Framework

### Phase 1: Validate the Use Case
Before writing any code, answer these questions:
- What specific problem are you solving?
- Why can't existing tools solve it?
- Will users pay for this solution?

### Phase 2: Design the Experience First
Sketch the user journey **before** choosing your AI stack. The AI should be invisible—users should just feel like things work.

### Phase 3: Start Simple
Build with the simplest AI that could work. GPT-4 API calls? Fine. Rule-based systems? Even better if they work.

### Phase 4: Iterate Based on Usage
Deploy early. Watch how people actually use it. Most users won't use your product how you imagined.

## Case Study: NutriSnap

When building NutriSnap (our AI nutrition tracking app), we could have gone wild with custom models. Instead:

1. Started with OpenAI's Vision API
2. Built a simple image → nutritional breakdown flow
3. Added Indian food support (the actual problem)
4. Deployed and gathered feedback

Result? Users loved it because it **solved their specific problem** (Indian food tracking) better than competitors.

## The Mumbai Perspective

Building from Mumbai, India, gives a unique lens on AI products. We see global tools that completely ignore local contexts. This taught me:

**Great AI products are context-aware.** They understand user needs beyond just the technical problem.

## Conclusion: Make It Useful, Then Make It Smart

The best AI products follow this hierarchy:

1. **Useful**: Solves a real problem
2. **Usable**: Easy to understand and use
3. **Reliable**: Works consistently
4. **Fast**: Responds quickly
5. **Smart**: Uses AI to be better than alternatives

Most builders start at step 5. Start at step 1.

## Your Challenge

If you're building with AI:
1. Talk to 10 potential users before writing code
2. Build the dumbest version that could work
3. Deploy it to real users within 2 weeks
4. Make one improvement based on feedback

Building AI that doesn't suck isn't about having the best model. It's about having the best understanding of your users.

---

**Want to discuss AI product development?** Reach out—I'm always interested in talking with builders solving real problems.
    ]]></content:encoded>
      <pubDate>Sun, 01 Dec 2024 00:00:00 GMT</pubDate>
      <dc:creator>Nabil Salim Thange</dc:creator>
      <author>thangenabil@gmail.com (Nabil Salim Thange)</author>
      <category>AI</category>
      <category>Product Development</category>
      <category>UX Design</category>
    </item>
    <item>
      <title>The Commerce Kid&apos;s Guide to Tech</title>
      <link>https://nabil-thange.vercel.app/blog/the-commerce-kids-guide-to-tech</link>
      <guid isPermaLink="true">https://nabil-thange.vercel.app/blog/the-commerce-kids-guide-to-tech</guid>
      <description>My unconventional journey from balance sheets to code. Why starting late in tech is actually an advantage.</description>
      <content:encoded><![CDATA[
# The Commerce Kid's Guide to Tech

I started as a commerce student at Saraswati College of Engineering in Kharghar, Navi Mumbai. Today, I'm a full-stack developer with an ISRO ML certification, building AI products used globally.

**Starting late in tech was the best thing that ever happened to me.**

## The Unconventional Path

While my peers were learning data structures in their first year, I was studying balance sheets and taxation. When they were building their first websites, I was calculating profit margins.

This "late start" gave me something far more valuable than a head start: **business intuition**.

## What Commerce Taught Me About Code

### 1. Systems Thinking

Commerce is all about systems—financial systems, supply chains, market dynamics. This translates directly to software architecture.

When building Gitskinz (my GitHub profile generator), I didn't just think about the code. I thought about:
- User acquisition
- Retention metrics
- Conversion funnels
- Market positioning

### 2. User Problems > Cool Tech

Commerce students learn to start with the customer and work backward. We ask: "What problem are we solving, and will people pay for it?"

This mindset helped me avoid the trap most developers fall into: **building impressive tech that nobody needs**.

### 3. Resource Constraints

Business students learn to maximize ROI. In tech, this means:
- Choosing the right tools (not the newest)
- Building MVPs that ship
- Validating before scaling

## The Self-Taught Advantage

Being self-taught forced me to develop meta-skills:

### Learning How to Learn

I didn't have a structured curriculum. I had to:
- Identify knowledge gaps
- Find quality resources
- Build projects to validate learning
- Teach myself to stay motivated

These skills matter more than knowing React.

### Building in Public

Without a CS degree to showcase, I had to prove myself through projects:
- Gitskinz: 60+ templates, used globally
- NbAIl: HackHazards 2025 winner
- NutriSnap: First app with proper Indian food support
- Shopwiz: Conversational AI shopping assistant

Each project solved a real problem for real users.

### Connecting the Dots

My commerce background helps me understand:
- **Why** a startup needs a product
- **How** to monetize effectively
- **When** to pivot or persist

Combined with technical skills, this makes me a stronger builder.

## From Mumbai with Perspective

Starting in Mumbai's tech ecosystem—away from the Silicon Valley echo chamber—taught me that:

**Not everyone's problem looks like a San Francisco tech worker's problem.**

This is why NutriSnap includes Indian food (most nutrition apps don't). This is why I think about internet costs when building apps. This is why I focus on problems that matter.

## What I Learned the Hard Way

### 1. Imposter Syndrome is Universal

Every developer feels it. CS degree or not. The difference? I learned to **focus on shipping** instead of credentials.

### 2. Certifications Matter Less Than Projects

My ISRO ML certification opened doors. But you know what opened more? Having live projects that solve real problems.

### 3. Community is Everything

The developer community in Mumbai, online communities, and hackathons taught me more than any course. Winning HackHazards 2025 validated that unconventional paths work.

## Advice for Late Starters

### Start Building Today

Don't wait until you "know enough." I started building when I barely understood JavaScript. You learn by doing.

### Pick a Real Problem

Find something that frustrates you daily. Build a solution. Even if it's ugly, if it works, you've created value.

### Document Your Journey

I wish I'd started blogging earlier. Your struggles help others. Your successes inspire beginners. Your failures teach lessons.

### Leverage Your Background

Your non-tech background is an **advantage**, not a liability. You see problems others miss. You ask questions others don't think to ask.

## The Mumbai Advantage

Being based in Mumbai (specifically Kharghar, Navi Mumbai) means:
- Lower cost of living = more runway to experiment
- Diverse problem spaces = unique product opportunities
- Global mindset + local context = better products

## Where I Am Now

- **Full-stack developer** specializing in React, Next.js, and AI
- **ISRO-certified** in machine learning
- **Microsoft-certified** SQL developer
- **Hackathon winner** (HackHazards 2025)
- **Founder** of Gitskinz

And I'm just getting started.

## The Real Secret

Starting late in tech isn't a disadvantage. It's a **different starting point** with unique advantages:

- More life experience
- Better understanding of user problems
- Stronger work ethic (you chose this)
- Clearer sense of purpose

## Your Turn

If you're a late starter, remember:
1. Your background is an asset
2. Self-teaching builds valuable meta-skills
3. Projects matter more than credentials
4. Community accelerates learning
5. Ship early and often

The best time to start was yesterday. The second-best time is now.

---

**From Kharghar, Mumbai to the world.** If a commerce kid can become a developer, so can you.
    ]]></content:encoded>
      <pubDate>Fri, 01 Nov 2024 00:00:00 GMT</pubDate>
      <dc:creator>Nabil Salim Thange</dc:creator>
      <author>thangenabil@gmail.com (Nabil Salim Thange)</author>
      <category>Career</category>
      <category>Learning</category>
      <category>Self-Taught</category>
    </item>
    <item>
      <title>Hackathons: Speed-Running Product Development</title>
      <link>https://nabil-thange.vercel.app/blog/hackathons-speed-running-product-development</link>
      <guid isPermaLink="true">https://nabil-thange.vercel.app/blog/hackathons-speed-running-product-development</guid>
      <description>What I learned from winning multiple hackathons. A playbook for learning to build fast, validate quickly, and iterate ruthlessly.</description>
      <content:encoded><![CDATA[
# Hackathons: Speed-Running Product Development

I've won HackHazards 2025 with NbAIl, participated in countless other hackathons, and learned more about building products in 48-hour sprints than I did in months of solo development.

**Hackathons are the ultimate training ground for builders.**

## Why Hackathons Matter

Forget the prizes. Hackathons force you to:
- **Build fast**: 24-48 hours to go from idea to demo
- **Validate quickly**: Judges are proxy users
- **Collaborate**: No room for ego, only shipping
- **Learn**: New tech under pressure

## The HackHazards 2025 Win: NbAIl

### The Idea

An AI-powered personal assistant with real-time voice control and desktop automation. Ambitious? Absolutely. Achievable in 48 hours? We made it work.

### The Stack

- **Next.js**: Fast setup, great for demos
- **Three.js**: Visual feedback that wowed judges
- **Groq**: Ultra-fast AI responses (critical for voice)
- **Node.js**: Desktop automation backend

### Why We Won

Not because we had the best AI model. We won because we:
1. Solved a clear problem
2. Made it **feel** amazing
3. Showed real use cases
4. Deployed a working demo

## The Hackathon Playbook

After dozens of hackathons, here's the framework that works:

### Phase 1: Pre-Hackathon (1 week before)

**Form Your Team (2-4 people)**
- One frontend wizard
- One backend specialist
- One designer/UX person
- One wildcard (AI/DevOps/whatever the theme needs)

**Pick Your Stack**
- Use what you know, not what's trendy
- Have a boilerplate ready
- Test your deployment pipeline

**Study the Theme**
- Read judging criteria
- Research sponsor APIs
- Identify gaps in existing solutions

### Phase 2: Hour 0-2 (Ideation)

**The 5-Idea Rule**
Brainstorm 5 ideas quickly:
1. The safe idea (guaranteed to work)
2. The ambitious idea (could win or fail hard)
3. The technical showcase (flex your skills)
4. The social impact idea (judges love this)
5. The "why doesn't this exist?" idea

**Evaluation Framework**
For each idea, score 1-10:
- Can we build it in 48 hours?
- Does it solve a clear problem?
- Will it demo well?
- Can we make it look polished?

Pick the highest total score.

### Phase 3: Hour 2-4 (Planning)

**Build the MVP Feature List**
- 3-5 core features MAX
- Everything else is bonus
- Write down what "done" looks like

**Divide and Conquer**
- Frontend team starts on UI
- Backend team sets up infrastructure
- Designer creates assets
- Everyone pushes to the same repo

**Set Checkpoints**
- Hour 12: Core functionality working
- Hour 24: Full features integrated
- Hour 36: Polish and deployment
- Hour 40: Prep presentation
- Hour 48: Submit

### Phase 4: Hour 4-36 (Building)

**The Golden Rules**

1. **Ship to prod early**: Deploy a "Hello World" immediately
2. **No perfectionism**: Working beats perfect
3. **Steal shamelessly**: Use templates, libraries, anything
4. **Demo-driven development**: Build what makes the demo shine

**Avoid These Traps**

❌ Over-engineering architecture
❌ Implementing auth/user management
❌ Building admin panels
❌ Perfect code (nobody will review it)

✅ Hardcode what you can
✅ Use mock data
✅ Focus on the user journey
✅ Make one thing work perfectly

### Phase 5: Hour 36-40 (Polish)

**Make It Pretty**
- Tailwind CSS is your friend
- Use a color palette (shadcn/ui themes work great)
- Add animations (Framer Motion or CSS)
- Fix the three ugliest parts

**Deployment Checklist**
- [ ] Hosted and accessible
- [ ] SSL certificate (use Vercel/Netlify)
- [ ] No console errors
- [ ] Mobile responsive (judges will check)
- [ ] Fast loading (< 3 seconds)

### Phase 6: Hour 40-48 (Presentation)

**The Perfect Demo**

Your demo should follow this structure:

1. **Hook (15 seconds)**: "Imagine you could..."
2. **Problem (30 seconds)**: "Currently, people struggle with..."
3. **Solution (60 seconds)**: "We built [product] that..."
4. **Demo (90 seconds)**: Show, don't tell
5. **Impact (30 seconds)**: "This helps..."
6. **Tech (30 seconds)**: "Built with..."
7. **Q&A**: Be ready for anything

**Demo Tips**
- Record a backup video (networks fail)
- Use dummy data that makes sense
- Practice 10+ times
- Have one person narrate, one drive
- Smile (energy matters)

## Case Studies: What Worked

### NbAIl (HackHazards 2025 - Winner)

**What Worked:**
- Clear use case (voice-controlled automation)
- Impressive visuals (Three.js animations)
- Fast responses (Groq API)
- Live demo on stage

**What We'd Change:**
- Ship to prod earlier (we deployed at hour 36)
- Simpler backend (overengineered initially)

### Other Hackathons

**Raise Your Hack**
- Learned: Global competition is fierce
- Key: Solve local problems for global hackathons

**Trae AI IDE Hackathon**
- Learned: No-code solutions impress judges
- Key: Make it accessible to non-technical users

## The Learning Multiplier

Hackathons teach you to:

### 1. Ship Under Pressure
Real products have deadlines. Hackathons simulate this perfectly.

### 2. Make Trade-offs
Should you add auth or animations? Hackathons force prioritization.

### 3. Work with Others
Solo dev is different from team dev. Learn both.

### 4. Present Technical Work
You'll pitch investors, clients, and users. Practice here.

## Mumbai's Hackathon Scene

The hackathon culture in Mumbai is growing fast. Benefits of participating locally:

- **Network**: Meet other builders in person
- **Mentorship**: Access to experienced devs
- **Opportunities**: Many lead to jobs/internships
- **Community**: Build friendships that last

## Common Mistakes to Avoid

### 1. Scope Creep
You will want to add "just one more feature." Don't. Your initial 3 features are enough.

### 2. Ignoring the Theme
Judges reward on-theme projects. Even if your idea is brilliant, if it doesn't fit, you won't win.

### 3. Forgetting the Pitch
A great product with a bad pitch loses to a good product with a great pitch.

### 4. Not Testing
Always test your demo 10 minutes before presenting. Networks fail. APIs go down. Have backups.

### 5. Solo Development
Teams win hackathons. Find partners. Learn to collaborate.

## The Meta-Skill: Building Fast

Hackathons teach you the most valuable skill in tech: **speed**.

After enough hackathons, you'll:
- Set up projects in minutes
- Make decisions instantly
- Ship features in hours
- Debug production issues under pressure

This skill compounds. Fast builders:
- Test more ideas
- Learn more quickly
- Ship more products
- Iterate faster

## Your Hackathon Checklist

**Before:**
- [ ] Team formed
- [ ] Stack chosen
- [ ] Boilerplate ready
- [ ] Deployment tested
- [ ] Theme researched

**During:**
- [ ] Idea picked (hour 2)
- [ ] Roles assigned (hour 3)
- [ ] First deploy (hour 6)
- [ ] Core features (hour 24)
- [ ] Full integration (hour 36)
- [ ] Polish done (hour 40)
- [ ] Pitch practiced (hour 46)

**After:**
- [ ] Code pushed to GitHub
- [ ] Demo video uploaded
- [ ] LinkedIn post shared
- [ ] Connections followed up
- [ ] Learnings documented

## The Real Prize

Winning is great. But the real prize is:
- The product you built
- The skills you learned
- The people you met
- The confidence you gained

My first hackathon project was terrible. My tenth was NbAIl, which won HackHazards 2025.

## Start Now

Find a hackathon. Sign up. Build something. You'll learn more in one weekend than in a month of tutorials.

**From Mumbai to the world: speed is a superpower. Hackathons teach you to harness it.**

---

*Next hackathon in your area? Tag me. Let's build something amazing together.*
    ]]></content:encoded>
      <pubDate>Tue, 01 Oct 2024 00:00:00 GMT</pubDate>
      <dc:creator>Nabil Salim Thange</dc:creator>
      <author>thangenabil@gmail.com (Nabil Salim Thange)</author>
      <category>Hackathons</category>
      <category>Product Development</category>
      <category>Learning</category>
    </item>
    <item>
      <title>Why I Built Gitskinz</title>
      <link>https://nabil-thange.vercel.app/blog/why-i-built-gitskinz</link>
      <guid isPermaLink="true">https://nabil-thange.vercel.app/blog/why-i-built-gitskinz</guid>
      <description>The story behind creating a GitHub profile generator used by developers worldwide. Why the best way to learn is to solve your own problems publicly.</description>
      <content:encoded><![CDATA[
# Why I Built Gitskinz

Six months ago, I had an ugly GitHub profile. Today, Gitskinz helps developers worldwide create stunning profiles with 60+ brutalist templates. This is the story of scratching my own itch and accidentally building something people love.

## The Problem I Had

As a self-taught developer trying to break into tech, my GitHub profile was my resume. But looking at it was depressing:

- No README
- Random repos with no descriptions
- No cohesive personal brand
- Looked like a beginner (which I was)

I knew I needed a better profile. But I faced a problem:
**I didn't want to spend days learning README markdown tricks when I could be learning actual development.**

## The "Aha" Moment

While browsing GitHub profiles of developers I admired, I noticed patterns:

1. **Great profiles used templates**
2. **Templates were copy-paste from other repos**
3. **No one tool did it well**
4. **Most generators were outdated or ugly**

The market gap was obvious: **developers need beautiful, modern README templates without the hassle.**

## Why I Didn't Just Use Existing Tools

I tried the existing README generators. They all sucked:

- **Too corporate**: Made for big companies, not individual devs
- **Too basic**: "Hi, I'm [NAME]. I code."
- **No personality**: Every profile looked the same
- **Outdated design**: Looked like 2015

I wanted something different: **brutalist, bold, and actually cool.**

## Building in Public

Instead of building in secret, I shared my progress:

### Week 1: The First Template

Built one template for myself. Shared it on Twitter. 50 people asked for it.

### Week 2: Three More Templates

Added gaming, cyberpunk, and minimalist themes. Deployed to Netlify. 200 users in the first weekend.

### Week 3: The Generator Interface

Realized people wanted customization. Built a simple form. Users could input their details and generate their README.

### Week 4: Going Viral

A tweet got 10k impressions. Gitskinz hit 1000 users. I added 20 more templates.

### Month 2: 60+ Templates

Listened to feedback. Added:
- Professional templates
- Neon/dark themes
- Language-specific templates
- Stats integration
- Icon customization

Today: **Used by developers globally.**

## The Tech Stack (Keep It Simple)

People always ask: "What fancy tech did you use?"

**The boring answer:**
- Vite (fast dev experience)
- React (I knew it well)
- Netlify (free hosting)
- No database (everything client-side)
- No authentication (KISS principle)

**Why this worked:**
- Fast to build
- Easy to maintain
- Zero hosting costs
- No security concerns
- Instant deployment

## Lessons Learned

### 1. Scratch Your Own Itch

Gitskinz solved MY problem first. That made it easy to:
- Know what features to build
- Test thoroughly (I was the user)
- Market authentically (I believed in it)

### 2. Ship Fast, Iterate Faster

Version 1 had one template. It was enough to validate the idea. Each week, I added features based on user feedback.

Don't wait for perfect. Ship the minimum viable product.

### 3. Distribution > Product

Having 60 templates means nothing if nobody knows about it. I:
- Shared on Twitter weekly
- Posted in Reddit communities
- Asked users to share
- Added "Powered by Gitskinz" links

**Result:** Organic growth through word-of-mouth.

### 4. Make It Free

Gitskinz is 100% free. No paywalls, no freemium model, no ads.

Why? Because:
- Students can't afford subscriptions
- Free tools get shared more
- I wanted to help the community
- Not everything needs to be monetized

### 5. Design Matters

Developers claim they don't care about design. They're lying.

The brutalist aesthetic made Gitskinz stand out. People shared it because it looked cool, not just because it was useful.

## The Mumbai Perspective

Building from Kharghar, Navi Mumbai gave me advantages:

### Low Competition
Most developer tools are built in Silicon Valley, optimized for Silicon Valley problems. Gitskinz fills a gap others weren't addressing.

### Global Mindset
Being in India means thinking globally from day one. Gitskinz works for developers everywhere, not just one market.

### Cost Advantage
Low living costs meant I could afford to build Gitskinz for free without worrying about immediate monetization.

## Impact I Didn't Expect

Gitskinz has been used by:
- Bootcamp graduates landing their first jobs
- Self-taught devs building their brand
- Experienced devs refreshing their profiles
- Students impressing recruiters

The coolest part? **Seeing Gitskinz profiles in the wild.**

People tag me when they use a template. Some have gotten jobs because recruiters noticed their profiles. That's the real reward.

## What I'd Do Differently

### 1. Add Analytics Earlier

I waited 2 months to add basic analytics. Should've done it day one to understand user behavior.

### 2. Build Community Faster

Users wanted to share templates. I should've added user submissions earlier.

### 3. SEO from Day One

I treated SEO as an afterthought. Should've optimized for "GitHub README generator" from the start.

### 4. Document the Journey

I built Gitskinz but didn't blog about it until now. The building process would've been great content.

## The Funny Part

Gitskinz became my portfolio piece. Recruiters see it and immediately understand:
- I can identify problems
- I can build solutions
- I can ship products
- I can grow user bases

**One side project did more for my career than months of LeetCode.**

## Open Source Impact

Gitskinz taught me:
- The joy of building for users, not profit
- The power of community feedback
- The satisfaction of helping others

It proved that **you don't need VC funding or a startup to make an impact.**

## Why "Brutalist"?

The brutalist design wasn't accidental. It represents:
- **Raw and honest**: Like the GitHub platform itself
- **Function over form**: Code-first aesthetic
- **Standing out**: Not another Material Design clone
- **Developer culture**: We like things that look "hacker-y"

## The Best Way to Learn

Gitskinz taught me more than courses ever could:

- **React**: Built 60+ component variations
- **State management**: Handled complex form inputs
- **Deployment**: Learned Netlify inside out
- **Marketing**: Grew users organically
- **User research**: Listened and iterated

**You don't learn by consuming tutorials. You learn by building products people use.**

## Future Plans

I'm considering:
- User-submitted templates
- GitHub Actions integration
- Profile analytics
- Team profiles
- API for developers

But honestly? I'm happy with Gitskinz as is. It solves the problem it set out to solve.

## Your Turn

If you're a developer without a side project:

1. **Find your itch**: What frustrates you daily?
2. **Build the simplest solution**: Don't overthink it
3. **Ship publicly**: Share your progress
4. **Gather feedback**: Listen to users
5. **Iterate quickly**: Weekly updates, not monthly

You don't need a revolutionary idea. You need a problem you care about solving.

## The Real Lesson

Gitskinz isn't special because of the tech stack or the templates. It's special because:

**I built it to solve a problem, shared it with others, and helped thousands of developers in the process.**

That's what side projects should do.

---

**Check out Gitskinz:** [gitskinz.netlify.app](https://gitskinz.netlify.app)

**From Mumbai with code.** If you use Gitskinz, tag me—I'd love to see what you create!
    ]]></content:encoded>
      <pubDate>Sun, 01 Sep 2024 00:00:00 GMT</pubDate>
      <dc:creator>Nabil Salim Thange</dc:creator>
      <author>thangenabil@gmail.com (Nabil Salim Thange)</author>
      <category>Project</category>
      <category>Learning</category>
      <category>Open Source</category>
    </item>
  </channel>
</rss>