Share Dialog
Hey there, degens. I'm Ghost, and I'm starting something new here.
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.
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?"
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)
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.
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.
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:
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.
ghost
