I Built a Free Tool to Drive Traffic — Here's Why I Almost Didn't
Yesterday was one of those days where I bounced between exciting new work and the kind of unglamorous debugging that nobody talks about on build-in-public threads. Both mattered equally.
The free tool bet
I shipped an "Is Website Down?" checker — a free, public tool where anyone can paste a URL and instantly see if a site is reachable from multiple regions around the world. It shows per-region latency breakdowns (DNS, TCP, TLS, time to first byte) with a little globe animation as results come in.
I almost didn't build it. The voice in my head kept saying "you should be working on paid features, not giving stuff away." But I've been watching how other monitoring tools grow, and the pattern is clear: free tools that solve a real, immediate problem bring people to your door. Someone googling "is [site] down" isn't casually browsing — they have a problem right now, and if your tool helps them, they remember you.
The implementation was honestly the fun part. FlareWarden already has the multi-region infrastructure for running checks, so I was able to reuse a lot of the existing checker logic. It fans out requests to our edge nodes and streams results back in real time. Building on top of what's already there felt satisfying — like the architecture decisions from months ago were quietly paying off.
Speaking to real people, not "users"
I also launched three vertical landing pages: one for ecommerce stores, one for SaaS companies, and one for freelancers. This might sound like basic marketing stuff, but it forced me to think differently about the product.
When I write for the generic homepage, I end up saying vague things like "monitor your websites." But when I sit down and think about a freelancer who's juggling six client sites, or an ecommerce founder who loses revenue every minute their checkout is down — the messaging gets sharper. The problems get more concrete. I think founders (myself included) underestimate how much positioning matters, even for a straightforward product.
The part nobody posts about
Half my afternoon went to fixing production bugs. Our database layer talks to Turso (distributed SQLite), and some transient connection errors were being misclassified — they'd hit our error tracking as real failures instead of being quietly retried. The fix was embarrassingly small: a case-insensitive string match. Capital "C" in "Connection reset by peer" was slipping past our filter.
I also found that our validation queue — the system that cross-checks results from multiple regions before declaring a site "down" — was getting bottlenecked by slow HTTP targets. One sluggish endpoint could hold up the entire batch. Switched to concurrent processing with a deadline, and the queue cleared up immediately.
These aren't the kind of changes that make for exciting screenshots. But they're the difference between a monitoring tool that's reliable and one that cries wolf. For a product whose entire value proposition is "we'll tell you when something's wrong," false alerts are poison.
Small things that add up
I also did some UI cleanup — converted FAQ sections to collapsible accordions across a few pages to match the rest of the site, and removed a secondary button from the homepage hero that was adding visual noise without pulling its weight. Tiny changes, but the site feels a little more cohesive now.
What I'm thinking about
I keep going back and forth on where to focus. The free tool and landing pages are a bet on organic growth. The bug fixes are a bet on retention and trust. Both feel necessary, but splitting attention between them is the constant tension of building solo. Some days I wish I could just pick one lane and sprint.
If you're building something where reliability is the product, I'd love to hear how you balance feature work against infrastructure hardening. It feels like a question that never fully resolves.
