Then I automated it to fire when I made real progress, and accidentally discovered something about how brains work.

The Hollow Celebration Problem

You know that feeling when you try to celebrate something but it feels forced? That was me with Raycast confetti. Birthday? Click. Random Friday? Click. Each trigger immediately forgotten.

The confetti wasn't the problem. The context was.

Manual celebration: "I should feel happy about this." Earned celebration: "I AM happy about this."

The difference changed everything.

The Real Enemy: Perfectionism Paralysis

Here's what my "productive" mornings looked like:

Start building a feature. Notice messy code. Fix the messy code. Notice inconsistent imports. Fix the imports. Notice a TODO from months ago. Address the TODO. Notice type errors. Fix the types.

Four hours later: Zero progress on the actual feature.

I wasn't being productive. I was being avoidant. Perfectionism is just fear wearing a productivity mask.

This pattern was killing me during a database migration project. 50+ files to migrate. Every file I opened revealed a dozen "quick fixes." Days turned into weeks of preparation with zero actual migration.

That's when the stupid idea hit: What if my computer celebrated when I shipped instead of when I polished?

The Accidental Discovery

I hooked up Raycast confetti to my git commits. Not for perfect code. Not for zero errors. For PROGRESS.

Ship a messy feature that works? Confetti. Complete one migration file? Confetti. Push code that moves things forward? Confetti. Actually deploy something users can touch? Double confetti.

My brain, apparently, is simpler than I thought. It just wants sparkles.

What Actually Happened to My Brain

Week one felt wrong. I was shipping code with TODOs. Committing functions that worked but weren't elegant. My inner perfectionist was screaming.

But the confetti kept coming. And something weird happened.

I started craving it.

Not the animation itself—the feeling of forward momentum it represented. My brain had connected "progress" with "reward" in a way that years of self-discipline never achieved.

I'd catch myself about to spiral into a refactoring rabbit hole and think: "Wait, this already works. Ship it, get confetti, move forward."

The database migration that had been stalled for weeks? Done in days. Not because I worked harder, but because I stopped polishing and started shipping.

The Psychology Is Universal

This isn't about code. It's about how brains work.

We think we're motivated by big rewards. The promotion. The launch. The perfect final product. But our brains are wired for immediate feedback. That's why social media is addictive—instant likes. That's why games work—constant micro-rewards.

Perfectionism short-circuits this. It delays all rewards until some imaginary future state of "done" that never arrives. Your brain, starved of dopamine, finds it elsewhere. Twitter. Reddit. Another coffee. Anything but the work.

But tiny, automated celebrations for imperfect progress? That's brain crack.

This Works for Everything

Writing? Celebrate words written, not perfect prose. I know someone who rigged their keyboard to play a typewriter ding every 100 words. They went from stuck to shipping blog posts weekly.

Exercise? Celebrate showing up, not perfect form. Automated calendar confetti for gym check-ins beats waiting to celebrate when you're "in shape."

Learning? Celebrate lessons completed, not mastery achieved. Progress bars and streak counters exist because they work.

Creative work? Celebrate iterations, not perfection. Every sketch, every draft, every prototype—each deserves recognition.

The pattern is always the same: Make progress visible. Make it celebrated. Make it automatic.

The Deeper Truth

Perfectionism tells you this story: "I'll be happy when it's perfect."

But perfect never comes. So happiness never comes. So you never ship.

Small, automatic rewards tell a different story: "I'm happy because I'm moving forward."

And movement builds momentum. And momentum builds habits. And habits build remarkable things—imperfect, shipped, real things that actually exist in the world.

Try This

Pick your biggest stuck project. The one you keep "almost finishing."

Find your version of confetti. Could be actual confetti. Could be a sound. Could be a victory dance. Whatever gives you that little hit of "yes!"

Automate it to trigger on progress, not perfection. Every small step forward. Every imperfect iteration. Every messy first draft.

Give it one week.

Your brain is simpler than you think. It just wants to feel good about moving forward. So let it.

The confetti didn't make me a better developer. It made me someone who actually ships.

Sometimes the best productivity hack isn't about discipline. It's about making your brain want to do the thing you've been avoiding.

Even if that means desktop confetti.

Find me shipping imperfect things daily:

JSONbored - Overview

DevOps × AI × Web3 | From blockchain validators to AI automation workflows - transforming how companies operate at scale. - JSONbored

https://github.com

Check out @raycast—they accidentally solved perfectionism (and if you want to try it out, you can save 10% on a Pro subscription with my referral link).

I build infrastructure for Web3 - mostly Cosmos validators and private blockchain tooling. My background is DevOps/infrastructure engineering with a healthy dash of entrepreneurship (aka "let's see if this thing can make money"), not traditional development. But somewhere between keeping production systems alive at 3 AM and explaining to validators why their nodes aren't syncing, I discovered something: I learn best when everything goes spectacularly wrong.

For the past few months, I've been bouncing between projects like a caffeinated ping-pong ball. A crypto gas tracker that accidentally became enterprise-grade Web3 infrastructure. A CLI tool that nobody asked for but I built anyway. Three different attempts at "the perfect development setup" that all ended in configuration hell.

The common thread? I keep doing things the hard way. Not intentionally – I'm not a masochist (despite what my commit history suggests). But somehow every "simple weekend project" turns into a masterclass in architectural decision-making, usually involving at least one "oh shit, that's not how that works" moment.

The Pattern

It goes like this:

Week 1: "This will be easy" 
Week 2: "Okay, maybe not that easy"
Week 3: "Why is everything on fire?"
Week 4: "Actually, this is better than what I originally planned"

Take the gas tracker. Started as a simple data fetch because I was tired of checking five different sites to see if Base was cheaper than Polygon. Ended up rebuilding the entire thing on Cloudflare Enterprise because I accidentally DDoS'd myself with my own enthusiasm.

That's not a flex – that's just what happens when you assume "it'll be fine" is a valid scaling strategy. (Spoiler: Vercel disagreed.)

But here's the thing: those detours taught me more than any tutorial ever could. When you're building Web3 tools that traders and DeFi users depend on for real transactions, the stakes feel different. Suddenly you care about things like "will this work when 1000 people are checking gas prices during a market dump?" instead of "does it work on my machine?"

What You'll Find Here

This isn't going to be another "10x developer shares their secrets" blog. It's more like "1x infrastructure guy learns to ship Web3 tools in public."

• Build decisions that seemed brilliant at 2 AM (spoiler: they weren't)

• Technologies I'm experimenting with (TanStack Start, Drizzle ORM, Cloudflare Workers, self-hosted AI with Ollama)

• The gap between "works in my homelab" and "works when real money depends on it"

• Process improvements that actually stick vs. ones that die after two weeks of good intentions

• Tools that change how I work (and tools that just create expensive new problems)

The Honest Part

I don't have this figured out. I'm not running a unicorn startup or managing a team of 50 engineers. I'm just someone who enjoys building things, breaking them, and building them better the second time around.

Some posts will be technical deep-dives into why Service Bindings are actually magic. Others will be "why did I spend three days optimizing something that literally no one will ever notice." A few will probably be me realizing I've been doing something wrong for years and somehow nobody told me.

The entrepreneurial side of me wants everything to scale and make money. The infrastructure engineer in me wants everything to be bulletproof and never break. The curious tinkerer just wants to see what happens when you combine three technologies that probably shouldn't be combined.

The goal isn't to position myself as an expert. It's to document the messy, iterative process of learning through building. Maybe you'll find it useful. Maybe you'll just enjoy watching someone else make mistakes first.

Why Document This?

Because the sanitized "how I built X" posts skip the best parts. They don't mention the week you spent debugging something that turned out to be a typo in an environment variable. Or the architectural decisions you made because you didn't know a better way existed (yet).

Building in public isn't just about sharing wins. It's about normalizing the fact that reliable Web3 infrastructure comes from a lot of not-quite-right experiments first. And sometimes the best learning happens when your "simple script" accidentally becomes a tool people actually use for real transactions.

What's Next

I'm currently rebuilding that gas tracker with a completely different architecture – because apparently I enjoy starting over. There's a CLI tool that's 80% done and will probably stay that way forever (the last 20% is always the hardest). I'm experimenting with some edge computing stuff that might be brilliant or might be solving problems that don't actually exist.

All of it will end up here, documented as it happens. The successes, the false starts, the moments where I realize I've been overthinking something simple or underthinking something complex.

If you're building things too – especially if you're the type who starts "quick experiments" that turn into multi-month rebuilds – stick around. We can figure this out together.

Next week: "I Automated Base Learn So You Don't Have To" – 13 SBTs, zero manual deployments.

Find me building Web3 tools in public:

JSONbored - Overview

DevOps × AI × Web3 | From blockchain validators to AI automation workflows - transforming how companies operate at scale. - JSONbored

https://github.com

Follow along for the ride – I'll be documenting every experiment, failure, and occasional win. Whether you're into Web3 infrastructure, learning new frameworks, or just enjoy watching someone figure things out in real-time, there's probably something here for you.