There's a moment in every project when you realize you've been building the wrong thing.For me, that moment came four times.The Setup
There's a moment in every project when you realize you've been building the wrong thing.
For me, that moment came four times.
The Setup
Nine months ago I moved from Poland to the Netherlands.
Not for a tech job - for a warehouse position. Order picker.
15-20km walking daily, scanning barcodes, loading pallets.
By day: warehouse worker.
By night: building software on a 2014 laptop hitting 94°C.
I wanted to build a PC monitoring tool.
Not another dashboard showing "CPU: 87%"
but something that tells you WHY. Which process. Which background app.
WHAT MAKES VOLTAGE JUMP?
The difference between monitoring and understanding.
Simple concept. What followed was mass less simple.
Rebuild #1: The "It Works" Trap
My first version looked like Windows 95 having a panic attack.
My first version looked like Windows 95 having a panic attack.
``
What I built:
Emoji spam everywhere (thought it was "modern")
Vertical stacks requiring endless scrolling
No visual hierarchy whatsoever
15+ features nobody asked for ``
But it worked. Technically. Numbers updated. Data was accurate.
I was proud for about two weeks.
Then I used it daily and learned my first brutal lesson:
"Working" isnt "Good"
There's a massive gap between "code runs" and "I'd actually want this on my screen."
Lines written: ~15,000
Lines deleted: ~15,000
Time wasted: 2 months
Rebuild #2: The Architecture Astronaut Phase
Classic mistake. Went full "proper engineering":
``
What I thought mattered:
Event-driven architecture ✓
Modular plugin system ✓
Clean separation of concerns ✓
Proper design patterns ✓
What users saw:
Bad mobile app running on desktop
Confusing navigation
Features nobody needed ``
Spent 2 weeks building automatic fan control. Beautiful code. Drag-and-drop curves. Real-time preview.
Then I tested it properly.
One wrong curve is potentially fried GPU.
Deleted everything.
Features built and killed: 29
Lesson: Just because you CAN build it doesn't mean you SHOULD
The 3 AM Moment
Picture this:
Time: 3 AM
Laptop temp: 94°C
Fans: screaming
Me: just finished 10-hour warehouse shift
Git log: 400+ commits saying "fix" and "maybe this time"
And I asked myself: what am I actually building?
I was building a tool for users who want to understand their PC.
But I was coding like someone trying to prove they could write code.
Different goals. Different products.
That night I scrapped the UI. Again.
Rebuild #3: Asking The Right Question
Instead of "what features can I add?"
I asked "what does someone actually NEED to see?"
`
The answer was embarrassingly simple:
┌─────────────────────────────────────┐
│ CPU [████████░░] 78% RAM [██████░░░░] 62% │ ← Side by side. No scrolling.
├─────────────────────────────────────┤
│ TOP PROCESSES: │
│ ▓▓▓ chrome.exe 43% │ - Darkest = top consumer
│ ▓▓ discord.exe 22% │
│ ▓ windows_update 12% │ - Instant visual hierarchy
│ ░ vscode.exe 8% │
└─────────────────────────────────────┘
Click any process → instant details
`
Deleted 15,000 lines during refactoring.
39,000 to 24,000.
The product got BETTER as I removed code.
Then I Got Fired
December 22nd. Three days before Christmas.
Agency: "Trial didn't work out."
Me: In temporary housing. Dogs in Poland. Laptop dying. Project 70% done.
Logical response: panic, find job, abandon project.
What I did: started rebuild #4.
What 680 Hours Actually Looks Like
Let me be honest:
Hours coded: 680+ (after warehouse shifts)
Lines written: 39,000
Lines kept: 24,000
Complete UI rebuilds: 4
Features killed: 29
GPU monitoring attempts: 6 (5 failed)
Coffee consumed: 340+ cups
Max laptop temp: 94°C (survived somehow)
Tech Stack (for those curious)
Core: Python 3.11+
UI: Tkinter + CustomTkinter
System data: psutil, GPUtil, WMI
Architecture: Event-driven, modular
RAM footprint: ~30MB (optimized for potato hardware)
Why Tkinter? Because 30MB RAM footprint beats 300MB Electron bloat. And it runs fine on decade-old hardware.
What I Actually Learned
Motivation is useless. Disappeared week 2. Stubbornness stayed.
"Working code" is a trap. My first version worked perfectly. It was also garbage to use.
Delete more. Seriously. I removed 40% of my code and the product improved.
Constraints is resources. Dying hardware = zero bloat allowed. Every feature earned its place.
Show up when it's not fun. That's the only difference between shipped and abandoned.
Current Status
Shipping in weeks. Not because I'm fast - because I didn't quit.
Features that made the cut:
Real-time monitoring with actual process breakdown
Time travel debugging (see what was running 3 hours ago)
Custom fan curves with safety validation
AI-assisted diagnostics
30MB RAM footprint
If you're building something solo and it feels painfully slow — that's not failure.
