DEV Community: Wishot Cipher🎭

😱 I Lost Hours of Code That Git Never Tracked — Here’s How VS Code Saved My Life

Wishot Cipher🎭 — Mon, 05 Jan 2026 14:09:07 +0000

A developer’s nightmare while building DuesTracker and the hidden feature that saved everything

🎯 TL;DR

I spent an entire morning writing beautiful React components for DuesTracker (my university’s class payment management system). A git rebase conflict corrupted everything. My code vanished. Git couldn’t help because the files were never committed. But VS Code’s Local History feature — one I never knew existed — saved every single line.

🌅 The Morning: Everything Was Perfect

January 5th, 2026. I was in the zone.

For context, I’ve been building DuesTracker — a React + TypeScript + Supabase app to help manage class payment dues for ECE students at my university. Today was supposed to be a big milestone.

I had just finished implementing some seriously cool features:

✨ ProfessionalDropdown component with search, multi-select, keyboard navigation, and Framer Motion animations
📄 Complete PDF Export utility using jsPDF with professional headers and styled tables
🔐 Security configuration module with domain validation
🔄 DashboardSwitcher component for seamless admin/student view transitions
🛡️ Build protection with Terser minification

These weren’t just quick hacks — they were production-ready, beautifully crafted components.

Then I decided to commit:

“Alright, let me commit all these changes and push to GitHub”

Little did I know, those words would trigger a cascade of events that nearly cost me everything.

💀 The Disaster: When Git Becomes Your Enemy

Here’s what happened:

$ git status
interactive rebase in progress; onto d520815

⚠️ Wait, what? An interactive rebase was somehow in progress. I hadn’t started one.

No problem, I thought:

$ git rebase --abort
$ git pull --rebase origin main

The terminal showed success:

Successfully rebased and updated refs/heads/main.
Dropped 8fdd4db (duplicate commit - already in upstream)

But when I looked at my files…

They were gone.

ProfessionalDropdown.tsx — Gone 💔
pdfExport.ts — Gone 💔
security.ts — Gone 💔
DashboardSwitcher.tsx — Gone 💔
All my vite.config.ts changes — Reverted 💔

Hours of work. Vanished. In seconds.

😰 The Panic: Checking Git Reflog

My heart was racing. But I knew about git reflog:

$ git reflog -30
18afa92 HEAD@{0}: pull --rebase origin main (finish)
8fdd4db HEAD@{1}: rebase (abort): returning to refs/heads/main
18afa92 HEAD@{2}: commit: resolved a conflict
8fdd4db HEAD@{3}: commit: fix: scanner lifecycle, diagnostics...

Found it! 8fdd4db! Let me cherry-pick:

$ git cherry-pick 8fdd4db

Result:

The previous cherry-pick is now empty, possibly due to conflict resolution.

The Devastating Realization

The commit was already in upstream. But here’s the problem:

The new files I created this morning were NEVER committed.

They existed only in my working directory. Now they were gone.

❌ Git reflog couldn’t help
❌ Git stash was empty
❌ No .git backup of uncommitted files

I was about to accept my fate and rewrite everything from memory…

💡 The Discovery: VS Code’s Secret Weapon

While debugging with my AI assistant, we discovered something I had completely overlooked:

VS Code has a local history feature!

I quickly checked:

Get-ChildItem -Path "$env:APPDATA\Code\User\History" -Recurse

And there it was. Hundreds of files.

VS Code had been silently saving versions of every file I edited — automatically, in the background, without me ever knowing.

C:\Users\YourUsername\AppData\Roaming\Code\User\History\
├── -33ad014b\          # ProfessionalDropdown.tsx
│   ├── entries.json
│   ├── H746.tsx        # 12:26 PM ⏰
│   ├── Itgi.tsx        # 12:15 PM ⏰
├── -3718bc8b\          # pdfExport.ts
│   ├── EM0w.ts         # 12:20 PM ⏰
└── ...

Each folder had timestamped backups. The entries.json mapped to the original file path.

My code wasn’t lost. VS Code had my back the entire time. 🙌

🔧 The Recovery: Bringing Everything Back

Step 1️⃣: Find the History Folders

Get-ChildItem -Path "$env:APPDATA\Code\User\History" -Recurse -Filter "entries.json" | 
ForEach-Object { 
    $content = Get-Content $_.FullName | ConvertFrom-Json
    if ($content.resource -like "*Class-dues-tracker*") { 
        Write-Output "$($_.Directory.Name): $($content.resource)"
    }
}

Step 2️⃣: Get the Latest Version

$latestFile = Get-ChildItem -Path $historyPath -File | 
    Where-Object { $_.Name -ne "entries.json" } | 
    Sort-Object LastWriteTime -Descending | 
    Select-Object -First 1

Step 3️⃣: Automated Recovery Script

$mappings = @{
    "-33ad014b" = "src/components/ui/ProfessionalDropdown.tsx"
    "-3718bc8b" = "src/utils/pdfExport.ts"
    "6319c950" = "src/config/security.ts"
    "-61ef17a9" = "src/components/DashboardSwitcher.tsx"
    "7ee7ef46" = "vite.config.ts"
}

foreach ($folder in $mappings.Keys) {
    $histPath = "$env:APPDATA\Code\User\History\$folder"
    $destPath = $mappings[$folder]
    $latestFile = Get-ChildItem -Path $histPath -File | 
        Where-Object { $_.Name -ne "entries.json" } | 
        Sort-Object LastWriteTime -Descending | 
        Select-Object -First 1

    Copy-Item -Path $latestFile.FullName -Destination $destPath -Force
    Write-Output "✅ Restored: $destPath"
}

✨ Result:

✅ Restored: src/components/ui/ProfessionalDropdown.tsx
✅ Restored: src/utils/pdfExport.ts
✅ Restored: src/config/security.ts
✅ Restored: src/components/DashboardSwitcher.tsx
✅ Restored: vite.config.ts

Every. Single. Line. Recovered. 🎉

📊 The Final Commit

27 files changed, 5976 insertions(+), 552 deletions(-)
 create mode 100644 LICENSE
 create mode 100644 src/components/DashboardSwitcher.tsx
 create mode 100644 src/components/ui/ProfessionalDropdown.tsx
 create mode 100644 src/config/security.ts
 create mode 100644 src/utils/pdfExport.ts

5,976 lines of code saved. Not rewritten from memory. Not approximated. The exact code I wrote.

🎓 Lessons Learned: How to Never Lose Code Again

1. 💾 Commit Early, Commit Often

This is Git 101, but I got complacent.

New Rule: If you’ve written more than 30 minutes of code, commit it.

git commit -m "WIP: feature in progress"

Even imperfect commits are better than no commits.

2. 🕐 Know About VS Code Local History

VS Code has been saving your file history this whole time!

Access it:

Right-click any file → “Open Timeline” (bottom of Explorer)
Or navigate to: %APPDATA%\Code\User\History\ (Windows)

Configure it:

{
    "workbench.localHistory.enabled": true,
    "workbench.localHistory.maxFileEntries": 50,
    "workbench.localHistory.maxFileSize": 256
}

3. ⚠️ Never Force Git Operations Without Understanding

Commands like git rebase, git reset --hard, and git clean can destroy uncommitted work.

Before running them:

Check git status first
Commit or stash everything
Create a backup branch: git branch backup-just-in-case

4. 📦 Use Git Stash Before Risky Operations

# Before any risky git operation
git stash push -m "backup before rebase"

# If something went wrong
git stash pop

5. 💾 Set Up Auto-Save

In VS Code settings:

{
    "files.autoSave": "afterDelay",
    "files.autoSaveDelay": 1000
}

This ensures Local History captures your changes.

6. 🪝 Consider Git Hooks for Reminders

Create .git/hooks/pre-commit:

#!/bin/bash
UNCOMMITTED=$(git diff --stat | wc -l)
if [ "$UNCOMMITTED" -gt 100 ]; then
    echo "⚠️  You have $UNCOMMITTED lines of uncommitted changes!"
    echo "Consider committing more frequently."
fi

📂 Where VS Code Stores Local History

OS	Path
Windows	`%APPDATA%\Code\User\History\`
macOS	`~/Library/Application Support/Code/User/History/`
Linux	`~/.config/Code/User/History/`

Each edited file gets a folder with timestamped backups.

🛠️ Quick Recovery Script (Save for Emergencies!)

# recover-from-vscode-history.ps1
param(
    [string]$SearchPattern = "*your-project*",
    [string]$OutputDir = "./recovered"
)

$historyBase = "$env:APPDATA\Code\User\History"
New-Item -ItemType Directory -Force -Path $OutputDir | Out-Null

Get-ChildItem -Path $historyBase -Recurse -Filter "entries.json" | ForEach-Object {
    $content = Get-Content $_.FullName -Raw | ConvertFrom-Json
    if ($content.resource -like $SearchPattern) {
        $latestFile = Get-ChildItem -Path $_.Directory.FullName -File | 
            Where-Object { $_.Name -ne "entries.json" } | 
            Sort-Object LastWriteTime -Descending | 
            Select-Object -First 1

        if ($latestFile) {
            $fileName = Split-Path $content.resource -Leaf
            $destPath = Join-Path $OutputDir $fileName
            Copy-Item -Path $latestFile.FullName -Destination $destPath -Force
            Write-Host "✅ Recovered: $fileName" -ForegroundColor Green
        }
    }
}

Write-Host "`n📁 Files recovered to: $OutputDir" -ForegroundColor Cyan

Usage:

.\recover-from-vscode-history.ps1 -SearchPattern "*my-project*" -OutputDir "./recovered"

💭 Final Thoughts

This experience was terrifying but educational. I went from thinking I’d lost an entire morning’s work to recovering everything in minutes.

Key Takeaways:

✅ Git is powerful but only protects committed code
✅ VS Code Local History is your silent guardian
✅ Commit frequently — “WIP” commits are perfectly fine
✅ Know your recovery options BEFORE you need them

The next time you’re deep in a coding session, remember:

Commit early, commit often, and know that VS Code has your back.

🚀 About DuesTracker

This experience happened while building DuesTracker — a React + TypeScript + Supabase application for managing class payment dues at my university. It’s been a journey of constant learning, from React patterns to Supabase RLS policies, and now… disaster recovery.

Sometimes the best solutions aren’t complex — they’re hidden features in tools you already use every day.

💬 Your Turn!

Have you ever lost code and recovered it in an unexpected way? Share your war stories in the comments! 👇

What’s your biggest coding disaster? How did you recover?

Follow my journey building DuesTracker for more development insights, lessons learned, and technical deep-dives!

Tags: #git #vscode #webdev #javascript #typescript #react #devtips #productivity #beginners #programming

Building a Full-Stack Class Dues Tracker: Lessons from Real-World Problem Solving

Wishot Cipher🎭 — Tue, 25 Nov 2025 20:07:20 +0000

Introduction: When Campus Problems Meet Code

Picture this: It’s the first semester at university, and chaos reigns. Students don’t know who’s paid their class dues, the class treasurer has receipts scattered across three WhatsApp groups, and there’s zero accountability for how funds are spent. Sound familiar?

This was the exact problem that pushed me to build Class Dues Tracker — a comprehensive payment management system that transformed how our department handles finances. But more importantly, it became my crash course in full-stack development, teaching me lessons no tutorial could.

In this post, I’ll share my journey building this project from scratch, the technical challenges I faced, the solutions I discovered, and most importantly — what I learned about being a developer.

🎯 The Problem: More Than Just Tracking Payments

Before diving into code, I had to understand the real problem. It wasn’t just about tracking who paid — it was about:

Trust: Students wanted transparency on where their money went
Accountability: Admins needed proof of payments and spending
Efficiency: Manual tracking via spreadsheets was error-prone and slow
Security: Financial data needed proper protection
Accessibility: Both students and admins needed easy access from any device

This taught me my first major lesson: Great software solves human problems, not technical ones.

🏗️ Architecture Decisions: Why I Chose This Stack

The Tech Stack

Frontend: React 18 + TypeScript + Vite
Styling: Tailwind CSS + Framer Motion
Backend: Supabase (PostgreSQL + Auth + Storage)
Deployment: Vercel (Frontend) + Supabase Cloud (Backend)

Why This Stack?

1. React + TypeScript

TypeScript saved me countless hours of debugging. Type errors caught at compile-time rather than runtime were game-changers.
React’s component model made the UI incredibly maintainable.

Lesson Learned: Type safety isn’t overhead — it’s a productivity multiplier.

2. Supabase Over Building a Custom Backend

I initially considered building a Node.js/Express backend. Here’s why I chose Supabase instead:

// What I avoided building from scratch:
// - Authentication system with bcrypt
// - PostgreSQL database setup
// - File upload infrastructure
// - Real-time subscriptions
// - Row Level Security
// - Automated backups

Lesson Learned: Don’t reinvent the wheel. Use managed services for commodity features so you can focus on your unique value proposition.

3. Tailwind CSS for Rapid UI Development

Coming from vanilla CSS, Tailwind felt weird at first:

// Old me would write:
<div className="payment-card">

// New me embraces utility classes:
<div className="bg-white/10 backdrop-blur-lg rounded-2xl p-6 shadow-xl">

But once I got the hang of it, my development speed 10x’d. No more switching between CSS files and components.

Lesson Learned: Modern CSS frameworks aren’t just trendy — they genuinely make you faster.

🔐 Security: The Hardest Lessons Come from Mistakes

Mistake #1: Trusting the Frontend

My initial code looked like this:

// ❌ WRONG: Checking permissions on the client
if (user.isAdmin) {
  await supabase.from('payments').update({ status: 'approved' })
}

A user could just open DevTools, set user.isAdmin = true, and approve their own payment!

The Fix: Row Level Security (RLS)

-- ✅ RIGHT: Enforce permissions at the database level
CREATE POLICY "Only admins can approve payments"
ON payments FOR UPDATE
USING (
  EXISTS (
    SELECT 1 FROM admins 
    WHERE admins.student_id = auth.uid()
  )
);

Lesson Learned: Never trust the client. Security must be enforced at the database level.

Mistake #2: Exposing Sensitive Data

I was returning full student objects, including password hashes:

// ❌ WRONG: Returning everything
const students = await supabase.from('students').select('*')

The Fix: Explicit field selection

// ✅ RIGHT: Only return what's needed
const students = await supabase
  .from('students')
  .select('id, reg_number, full_name, email, level')

Lesson Learned: The principle of least privilege applies to data too. Only expose what’s absolutely necessary.

Mistake #3: Unvalidated File Uploads

Users were uploading any file type, including executables:

// ❌ WRONG: No validation
await supabase.storage.from('receipts').upload(file.name, file)

The Fix: Strict validation

// ✅ RIGHT: Validate type and size
const ALLOWED_TYPES = ['image/jpeg', 'image/png', 'application/pdf']
const MAX_SIZE = 5 * 1024 * 1024 // 5MB

if (!ALLOWED_TYPES.includes(file.type)) {
  throw new Error('Invalid file type')
}
if (file.size > MAX_SIZE) {
  throw new Error('File too large')
}

Lesson Learned: Validate everything. Users will break things in ways you never imagined.

💾 Database Design: Evolution Through Iterations

Version 1: The Naive Schema

My first attempt was too simple:

CREATE TABLE payments (
  id UUID PRIMARY KEY,
  student_id UUID,
  amount DECIMAL,
  paid BOOLEAN
);

Problems emerged immediately:

No audit trail (when was it paid? who approved it?)
No way to track different payment types
No transaction references for verification
No rejection reasons

Version 2: The Over-Engineered Schema

I then went to the opposite extreme, creating 8+ tables with complex relationships. Queries became nightmares.

Version 3: The Balanced Schema (Final)

CREATE TABLE payment_types (
  id UUID PRIMARY KEY,
  title VARCHAR(255),
  amount DECIMAL(10,2),
  deadline TIMESTAMP,
  bank_name VARCHAR(255),
  account_number VARCHAR(50),
  target_levels TEXT[],  -- Elegant solution for multi-level targeting
  is_active BOOLEAN DEFAULT true
);

CREATE TABLE payments (
  id UUID PRIMARY KEY,
  student_id UUID REFERENCES students(id),
  payment_type_id UUID REFERENCES payment_types(id),
  amount DECIMAL(10,2),
  transaction_ref VARCHAR(100) UNIQUE,
  receipt_url TEXT,
  status VARCHAR(20) CHECK (status IN ('pending', 'approved', 'rejected')),
  notes TEXT,
  rejection_reason TEXT,
  created_at TIMESTAMP DEFAULT NOW(),
  approved_at TIMESTAMP,
  approved_by UUID REFERENCES admins(student_id)
);

Lesson Learned: Database design is about finding the sweet spot between simplicity and functionality. Start simple, iterate based on real needs.

🎨 UI/UX: Building Trust Through Design

The Glassmorphism Trend

I implemented a glassmorphism design system:

const GlassCard = ({ children, className = '' }) => (
  <div className={`
    bg-white/10 
    backdrop-blur-lg 
    rounded-2xl 
    border border-white/20 
    shadow-xl 
    ${className}
  `}>
    {children}
  </div>
)

Why it worked:

Modern, trustworthy appearance
Excellent visual hierarchy
Performance: CSS filters are GPU-accelerated

Lesson Learned: Design isn’t just aesthetics — it’s communication. A professional UI builds trust, especially for financial applications.

Progress Visualization

Instead of just showing “25/50 paid”, I built a visual progress system:

<div className="relative">
  <div className="absolute inset-0 bg-gray-700 rounded-full" />
  <div 
    className="relative h-4 bg-gradient-to-r from-primary to-accent rounded-full transition-all duration-700"
    style={{ width: `${(paidCount / totalCount) * 100}%` }}
  />
  <div className="absolute inset-0 flex items-center justify-center text-xs font-bold">
    {paidCount}/{totalCount}
  </div>
</div>

The Impact: Students became more motivated to pay when they could see their classmates’ progress.

Lesson Learned: Visualizations aren’t just pretty — they drive behavior.

🐛 The Debugging Saga: My Biggest Technical Challenge

The Ghost Payment Bug

The most frustrating bug I encountered:

Symptom: Payments would submit successfully but wouldn’t appear in the admin review page.

4 Hours of Debugging Later…

// The culprit was in my query:
const { data } = await supabase
  .from('payments')
  .select('*')
  .eq('status', 'pending')
  .eq('payment_type_id', selectedType)  // This was undefined!

// The fix:
const { data } = await supabase
  .from('payments')
  .select(`
    *,
    student:students(full_name, reg_number),
    payment_type:payment_types(title, amount)
  `)
  .eq('status', 'pending')

What I Learned:

Silent failures are the worst — Add proper error logging
Use TypeScript enums for status values to catch typos
Supabase’s join syntax is powerful but requires practice
Test with real data, not just mock data

Lesson Learned: The debugger is your friend. console.log is good, but stepping through code is better.

🚀 Performance Optimizations: Making It Fast

Problem: Dashboard Was Slow

Initial load time: 3.2 seconds 😱

Optimization 1: Lazy Loading

// Before: All pages loaded upfront
import DashboardPage from './pages/DashboardPage'
import PaymentDetailPage from './pages/student/PaymentDetailPage'

// After: Code splitting with React.lazy
const DashboardPage = lazy(() => import('./pages/DashboardPage'))
const PaymentDetailPage = lazy(() => import('./pages/student/PaymentDetailPage'))

Result: Initial bundle size reduced by 60%

Optimization 2: Smart Data Fetching

// Before: Fetching everything
const payments = await supabase.from('payments').select('*')

// After: Only fetch what's needed
const recentPayments = await supabase
  .from('payments')
  .select('id, amount, status, created_at')
  .order('created_at', { ascending: false })
  .limit(5)

Optimization 3: Caching Payment Types

// Before: Fetching payment types on every render
useEffect(() => {
  fetchPaymentTypes()
}, [])

// After: Cache for 5 minutes
const [paymentTypes, setPaymentTypes] = useState<PaymentType[]>([])
const [lastFetch, setLastFetch] = useState<number>(0)

useEffect(() => {
  const now = Date.now()
  if (now - lastFetch > 5 * 60 * 1000) {
    fetchPaymentTypes()
    setLastFetch(now)
  }
}, [lastFetch])

Final Result: Dashboard load time: 0.8 seconds ✅

Lesson Learned: Performance optimization is about measuring first, optimizing second. Don’t optimize prematurely.

📱 Real-Time Features: The Magic of Subscriptions

One of the coolest features was real-time notifications:

useEffect(() => {
  const channel = supabase
    .channel('notifications')
    .on(
      'postgres_changes',
      {
        event: 'INSERT',
        schema: 'public',
        table: 'notifications',
        filter: `recipient_id=eq.${user.id}`
      },
      (payload) => {
        // Play sound
        playNotificationSound()

        // Show toast
        toast.success(payload.new.title)

        // Update UI
        setNotifications(prev => [payload.new, ...prev])
      }
    )
    .subscribe()

  return () => {
    supabase.removeChannel(channel)
  }
}, [user.id])

User Experience: When an admin approves a payment, the student instantly gets a notification with sound.

Lesson Learned: Real-time features create magical user experiences that make your app feel alive.

🧪 Testing: The Wake-Up Call

My Testing Journey

Stage 1: No tests, just YOLO deployment

Result: Production bugs, angry users

Stage 2: Wrote tests after the fact

Result: Tests were a pain to write for existing code

Stage 3: Test-Driven Development (TDD)

Result: Caught bugs before they reached production

A Testing Example

// paymentService.test.ts
describe('Payment Submission', () => {
  it('should reject payments with invalid transaction refs', async () => {
    const payment = {
      studentId: '123',
      paymentTypeId: '456',
      transactionRef: '', // Invalid: empty
      amount: 5000
    }

    await expect(submitPayment(payment))
      .rejects
      .toThrow('Transaction reference is required')
  })

  it('should prevent duplicate transaction references', async () => {
    const payment1 = { transactionRef: 'TRX123', /*...*/ }
    const payment2 = { transactionRef: 'TRX123', /*...*/ }

    await submitPayment(payment1)

    await expect(submitPayment(payment2))
      .rejects
      .toThrow('Transaction reference already exists')
  })
})

Lesson Learned: Tests aren’t optional for production apps. They’re your safety net when refactoring.

🎓 Soft Skills: The Unexpected Lessons

Communication > Code

The best code in the world is useless if users don’t understand it.

What I Did:

Created detailed documentation with screenshots
Recorded video tutorials for admins
Set up a feedback channel in our class WhatsApp group
Conducted user testing sessions with 5 students

Result: 80% user adoption in the first week.

Lesson Learned: Developer tools are for developers. User-facing products need user-focused communication.

Managing Scope Creep

Midway through, classmates kept requesting features:

“Can we add SMS notifications?”
“Can we integrate with mobile money?”
“Can we track individual expenses?”

I learned to say: “Great idea! Let’s add it to the roadmap for v2.”

Lesson Learned: Shipping a good v1 beats building the perfect product that never launches.

Handling Criticism

When I launched the beta, feedback was… harsh:

“The UI is confusing”
“Why do I need to upload a receipt?”
“The old way was simpler”

Instead of getting defensive, I:

Listened and took notes
Identified common complaints
Fixed the top 3 issues within 48 hours
Re-launched with improvements

Result: Sentiment shifted from skeptical to supportive.

Lesson Learned: Criticism is a gift. It’s free user research.

📊 Impact: By The Numbers

After 1 semester of use:

Metric	Before	After	Improvement
Payment Collection Rate	65%	94%	+45%
Average Collection Time	6 weeks	2 weeks	-67%
Financial Disputes	12	1	-92%
Admin Time Spent	8 hrs/week	1 hr/week	-87%
Student Satisfaction	3.2/5	4.6/5	+44%

Most Rewarding Moment: When the class president told me, “This changed everything. We can finally focus on events instead of chasing payments.”

🔮 What’s Next: Version 2.0

Features I’m planning:

Expense Tracking Module
Admins can log expenses
Students see where money goes
Generate financial reports
Mobile App
React Native version
Push notifications
Offline mode
Analytics Dashboard
Payment trends
Collection forecasting
Export reports
Integration Features
Mobile money APIs
Email notifications
SMS reminders

🎯 Key Takeaways for Aspiring Developers

1. Start with the Problem, Not the Tech

Don’t ask “What cool tech can I use?” Ask “What problem am I solving?”

2. Ship Fast, Iterate Faster

My first version was buggy. That’s okay. Real users give real feedback.

3. Security Can’t Be an Afterthought

Build it in from day one. Retrofitting security is painful.

4. Document Everything

Your future self (and contributors) will thank you. I wrote detailed README files, API docs, and setup guides.

5. Open Source Isn’t Just About Code

It’s about community, communication, and collaboration.

6. Learn by Building Real Projects

Tutorials taught me syntax. This project taught me engineering.

7. It’s Okay to Not Know Everything

I Googled constantly. I read documentation. I asked for help. That’s normal.

🛠️ Tools That Made Me 10x More Productive

GitHub Copilot - Autocompleting boilerplate saved hours
Supabase Studio - Visual database management was a game-changer
Figma - Designing UI before coding prevented rework
Postman - Testing API endpoints in isolation
Chrome DevTools - React DevTools and Network tab were essential
Vercel - One-click deployments = faster iteration
Linear - Task management kept me organized

💡 Resources That Helped Me

Documentation I Lived In:

Courses/Videos:

“Just Ship It” mindset from Pieter Levels
React patterns from Kent C. Dodds
Database design from Hussein Nasser’s YouTube

Communities:

Reddit: r/webdev, r/reactjs
Discord: Supabase Community
Twitter: #buildinpublic

🎬 Conclusion: The Journey Continues

Building this Class Dues Tracker taught me more than any course could:

Technical skills: Full-stack development, database design, security
Product thinking: User research, MVP, iteration
Soft skills: Communication, feedback handling, scope management
Real-world impact: Solving problems for real users

But the most important lesson? You don’t need to be an expert to build something useful.

I wasn’t a senior developer when I started this. I was just someone frustrated with a problem, willing to learn, and determined to ship.

If you’re reading this and thinking “I could never build something like this” — yes, you can. Start small. Break problems into pieces. Google relentlessly. And most importantly, just start.

📞 Let’s Connect

I’d love to hear your thoughts, questions, or your own project stories!

GitHub: @Wishot-Cipher
Project Repo: Class Dues Tracker
Twitter: @WishotStudio
LinkedIn: Wisdom Alom

- Email: wishotstudio@gmail.com

🙏 Thank You

To everyone who:

Beta tested the app
Gave feedback (even the harsh stuff)
Encouraged me when I wanted to quit
Shared this project

And to you, reading this — thanks for making it to the end. Now go build something awesome! 🚀

What’s your biggest challenge in your current project? Drop a comment below — I’d love to help!

This post is part of my #buildinpublic journey. Follow along as I continue iterating on this project and building new ones!

🚨 The Hidden Pitfall: Mixing Tailwind CSS v3 and v4 in Production

Wishot Cipher🎭 — Tue, 21 Oct 2025 10:31:04 +0000

When I built an AI-powered chatbot for my portfolio using React, Vite, and Tailwind CSS v4, everything worked beautifully — until deployment.

Once I pushed to Vercel, the build crashed hard.

The cause?

👉 Mixing Tailwind CSS v3 and v4 components in the same project.

Here’s what happened, what I learned, and how I fixed it.

📋 Table of Contents

The Setup: What I Was Building
The Mistake: Installing @tailwindcss/typography
Why It Worked Locally But Failed on Vercel
The Root Cause: Version Conflicts
The Solution: Clean Migration to v4
Custom Typography: Better Than the Plugin
Complete Setup Guide
Key Takeaways

🚀 The Setup: What I Was Building

I was creating an AI chatbot for my portfolio with these features:

Frontend: React 18 + Vite 6
Styling: Tailwind CSS v4
AI Integration: Groq API (Llama 3.1 70B Versatile)
Markdown Rendering: react-markdown + remark-gfm
Deployment: Vercel

The chatbot needed to render AI messages with bold, italics, code blocks, lists, and links — so I reached for @tailwindcss/typography.

❌ The Mistake: Installing @tailwindcss/typography

I ran this:

npm install @tailwindcss/typography

Then updated my component:

{isBot ? (
  <div className="prose prose-invert prose-sm md:prose-base">
    <ReactMarkdown remarkPlugins={[remarkGfm]}>
      {message.text}
    </ReactMarkdown>
  </div>
) : (
  <div className="text-sm md:text-base">{message.text}</div>
)}

Locally, everything worked perfectly.

AI responses looked clean and styled — until Vercel rejected the build.

🤔 Why It Worked Locally But Failed on Vercel

Locally, the dev server was lenient:

Vite dev server ignores strict dependency rules
Cached dependencies hid conflicts
Development builds don’t tree-shake or optimize

But Vercel’s production build was strict:

Error: The `@tailwindcss/typography` plugin is designed for Tailwind CSS v3.x
but you are using Tailwind CSS v4.x. These versions are incompatible.

Vercel installs fresh dependencies and performs strict checks — so it caught what local dev ignored.

🔍 The Root Cause: Version Conflicts

In package.json, I had:

"devDependencies": {
  "tailwindcss": "^4.1.14"
}

But running this:

npm list tailwindcss

Revealed this:

├── tailwindcss@4.1.14
└─┬ @tailwindcss/typography@0.5.10
  └── tailwindcss@3.4.1  ← Hidden dependency!

The typography plugin pulled in Tailwind v3, creating a version conflict.

Feature	Tailwind v3	Tailwind v4
Config	`tailwind.config.js`	CSS-first (`@import "tailwindcss"`)
PostCSS	Required	Optional (`@tailwindcss/vite`)
Plugins	JS config	CSS or standalone packages
Build	PostCSS	Vite-native

Mixing both leads to:

⚠️ Conflicting PostCSS transforms
⚠️ Duplicate utility generation
⚠️ Broken configuration detection
⚠️ Build failures

✅ The Solution: Clean Migration to v4

Step 1: Remove v3 Dependencies

npm uninstall @tailwindcss/typography postcss autoprefixer
rm tailwind.config.js postcss.config.js

Step 2: Verify a Clean v4 Setup

Your package.json should include only:

"devDependencies": {
  "tailwindcss": "^4.1.14",
  "@tailwindcss/vite": "^4.1.14",
  "vite": "^6.0.5",
  "@vitejs/plugin-react": "^4.3.4"
}

Step 3: Update Vite Config

// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [react(), tailwindcss()],
})

Step 4: Clean CSS Import

/* src/index.css */
@import "tailwindcss";
/* No need for @tailwind base; etc. */

Step 5: Reinstall Everything

rm -rf node_modules package-lock.json
npm install

🎨 Custom Typography: Better Than the Plugin

Instead of using the plugin, I built my own lightweight typography system — fully compatible with v4, more customizable, and no dependency conflicts.

Example: src/index.css

@import "tailwindcss";

.markdown-prose {
  line-height: 1.75;
  color: rgb(229 231 235);
}
.markdown-prose a {
  color: rgb(34 211 238);
  text-decoration: none;
  transition: color 0.2s;
}
.markdown-prose a:hover {
  text-decoration: underline;
  color: rgb(6 182 212);
}
.markdown-prose code {
  background: rgba(255,255,255,0.1);
  padding: 0.25rem 0.5rem;
  border-radius: 0.375rem;
  font-family: 'Courier New', monospace;
  color: rgb(249 168 212);
}
.markdown-prose pre {
  background: rgba(0,0,0,0.3);
  border-radius: 0.5rem;
  padding: 1rem;
  overflow-x: auto;
}

Component Update:

<div className="markdown-prose">
  <ReactMarkdown remarkPlugins={[remarkGfm]}>
    {message.text}
  </ReactMarkdown>
</div>

🧩 Complete Setup Guide

1. Install Dependencies

npm install react react-dom react-markdown remark-gfm
npm install -D vite @vitejs/plugin-react tailwindcss @tailwindcss/vite

2. Project Structure

my-project/
├── src/
│   ├── index.css
│   ├── main.tsx
│   └── components/
│       └── ChatBot.tsx
├── vite.config.ts
└── package.json

3. Test for Conflicts

npm list tailwindcss

✅ Only v4 should appear

🎯 Key Takeaways

💡 What I Learned

Local ≠ Production – Always test production builds locally.
Peer Dependencies Matter – npm list <package> is your friend.
Tailwind v4 ≠ v3 – It’s a full architecture shift.
Custom CSS Wins – Fewer dependencies, cleaner builds.
Vercel Is Strict – And that’s a good thing.

✅ Do

Test production builds before deploy
Read plugin compatibility docs
Keep dependencies minimal

❌ Don’t

Mix v3 and v4 packages
Ignore peer dependency warnings
Assume local dev = production ready

🔗 Resources

💬 Final Thoughts

Mixing Tailwind v3 and v4 is like trying to run diesel in an electric car — they’re built differently.

By going all-in with Tailwind v4 and replacing the typography plugin, I ended up with:

⚡ Faster builds
🎨 Fully custom styles
🚀 100% production compatibility
🔧 Easier maintenance

If you’re upgrading — migrate cleanly, don’t mix.

🙋‍♂️ Questions?

Found this helpful? Drop a comment or connect with me:

🌍 Connect with Me

💼 LinkedIn
🧑‍💻 GitHub
🪄 [Portfolio]— Under Contruction 🚧
🐦 X (Twitter)
✉️ wishotstudio@gmail.com

Last updated: October 2024

Tailwind CSS: v4.1.14 • React: 18.3.1 • Vite: 6.0.5