FlareWarden.com
Site protection that never sleeps, Uptime, SSL, DNS & more
I'm building FlareWarden, a solo-founded uptime monitoring tool. I put it out for feedback recently and got the kind of honest responses that make you close your laptop and go for a walk.
The two biggest hits:
1. "Your app feels vibe-coded." Someone pointed out that I'd basically built a top dropdown nav and stopped thinking about layout. Too many clicks to get to useful info. Nothing surfaced proactively. No dark mode. They were right — I'd been building for does this feature exist instead of can someone actually use this.
2. "Your branding isn't accessible." I had this teal/red palette with a shield logo that I genuinely loved. Deliberately avoided the dark-header-white-page SaaS look. But multiple people independently said the logo colors didn't pass accessibility checks and the brand wasn't landing. When several strangers agree on the same problem, it's not a taste issue.
What I did (2 weeks, dozens of features rewired):
Brand side — killed the shield, killed the red, moved from teal to emerald green, switched to a wordmark, and leaned into "Warden" as the visual anchor instead of "Flare." Simpler, more legible, actually accessible.
App side — full UI rebuild, same information architecture underneath. Persistent side menu showing all monitors with live updates. Dashboard that surfaces incidents across monitors with deep links instead of burying them. Contextual calendars on most pages. Actions moved into flyover panels so you stay in context. Nearly everything updates live without page reloads.
The approach shift was the real change: before I built functionality and gave it a representation. This time I designed for usability, clarity, and information density first, then wired the functionality back in.
The hardest part: rebuilding features you already have into a new interface. You're not shipping anything new. You're just making what exists actually good. It's the most tedious kind of work because there's no dopamine hit of "new feature launched" — just the slow grind of "this interaction is slightly less annoying now."
The thing I'm still not sure about: I genuinely liked my old brand. It was different. The new one is objectively better but also safer. Has anyone else gone through this — killing a brand you liked because the feedback was clear, and still second-guessing it after?
Old Design
New Design
Cron Jobs... very different than what we do so far. So far everything is outreach, you enter data, we reach out and return results, and compile them. Cron Jobs are different because you set them up, we provision a URL, and you reach out to the URL to let us know the status. And when we have failure, things running late, etc we report it.
It will be a bit before we can release it. But the core functionality is working, now we just need to polish it and fix bugs and issues around the edges. Slowly building a complete platform.
What should I work on Next?
Spent a chunk of yesterday debugging why FlareWarden's "Is Website Down?" tool wasn't returning cross-region results in production. Worked perfectly locally. The tool checks a URL from multiple Fly.io regions to give you a global picture, and the multi-region part was just... not working.
Turned out to be a host routing issue. When one Fly machine pings another internally, the Host header is an internal IP, not a real domain. My HostRouter didn't recognize it, so the request fell through to the status page router, which returned 404. Three lines changed in the middleware. Classic "obvious in hindsight" bug that took way too long to find because the logs just showed clean 404s with no context about why.
While I was in that area of the code I also added dynamic OG images — so when someone checks ?url=https://example.com, the social preview shows "Is example.com Down?" instead of the generic title. Small thing but it makes shared links look way more intentional.
The rest of the day was SEO gruntwork. Added FAQ accordion sections and JSON-LD structured data across all 19 marketing pages. Not glamorous but Google eats that stuff up. Also fixed a CSS issue where decorative SVG underlines on headings were stretching to full container width on mobile instead of hugging the text. Had to add between the last two words on 26 headings to prevent orphaned words at mobile breakpoints too. Touched 21 templates for that one.
Some days you ship features, some days you fix underlines on 26 headings.
Yesterday I shipped 13 commits to FlareWarden. Zero of them were new features. Zero of them were things a user requested. And I think it was one of the most important days of work I've done on this project.
The SEO rabbit hole
I've been reading a lot about how other bootstrapped SaaS founders get organic traffic, and the consensus is painfully clear: if you're not creating dedicated landing pages for the exact phrases people Google, you basically don't exist. So I spent a big chunk of the day building out three new feature pages — one for SSL monitoring, one for domain monitoring, and one for content monitoring.
These aren't fluff pages. Each one maps directly to something FlareWarden already does. But until yesterday, if someone searched "ssl expiration monitoring" or "domain monitoring tool," there was nothing on my site that specifically spoke to that intent. The product could do it. The marketing didn't say so.
I also wrote a longer blog post — a "what is downtime?" pillar article — targeting a keyword with decent volume and low competition. The idea is to build a content foundation that the feature pages can link into and vice versa. Whether any of this actually moves the needle, I genuinely don't know yet. But sitting around waiting for traffic that isn't coming felt worse than trying.
Fixing things I didn't know were broken
While building the blog post, I discovered that my publish date filtering was completely broken. Posts with future dates were showing up immediately. The bug was subtle — my YAML parser was returning dates as a different data type than I expected, so the filter was silently passing everything through. One of those bugs that never causes an error, just quietly does the wrong thing. Mildly infuriating.
I also found that some of my blog posts were citing competitors as sources. Not intentionally — when I'd written educational content, I'd linked to whatever had the best explanation, and some of those happened to be monitoring companies I compete with. Cleaned all of that out and replaced them with neutral sources. Small thing, but it felt sloppy to leave it.
The homepage got a real demo
The biggest visual change was replacing the static dashboard screenshot on the homepage with an animated walkthrough. It cycles through three steps: entering a URL, watching monitors get auto-discovered, and seeing a live status page. All pure CSS, no JavaScript. It loops every 12 seconds.
I'm genuinely torn on whether this is better. The old screenshot was simple and clear. The animation tells more of a story, but it's also more complex and there's a risk people just scroll past it. I added a reduced-motion fallback that shows the final state as a static image, which felt like the right thing to do. We'll see how it performs.
"Founding Member" is dead, long live "Early Adopter"
I went through the entire codebase — emails, legal pages, billing, registration, marketing — and replaced every instance of "Founding Member" with "Early Adopter." This was a positioning decision I'd been putting off. "Founding Member" sounds exclusive, but it also sounds like the product is brand new and unproven. "Early Adopter" communicates the same discount benefit while framing users as savvy rather than charitable.
Along the way, I rewrote a lot of the urgency-driven copy. Stuff like "lock in 40% OFF forever" became "your rate never increases, even as we add features." Same deal, less used-car-lot energy. I also redesigned the registration page's plan selector to be more scannable — horizontal rows instead of stacked cards.
The honest take
Days like yesterday feel productive in the moment but anxious afterward. None of this ships a feature. None of it directly solves a user's problem. It's all positioning and polish and hoping that Google notices. The rational part of my brain knows this groundwork matters. The founder part of my brain wants to see a signup notification.
I keep reminding myself that the product is solid. The monitoring works. The checks run. What's missing isn't capability — it's visibility. So that's what I'm building toward, one landing page at a time.
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.
Yesterday I shipped something that might sound counterintuitive: I added a section to every single competitor comparison page on FlareWarden that invites visitors to go ask Claude, ChatGPT, or Perplexity whether my product is actually better than the alternative.
Every comparison page — Pingdom, UptimeRobot, Better Stack, Datadog, StatusCake, Freshping, Instatus — now has a "Don't just take our word for it" block at the bottom with pre-filled prompts that open directly in each AI tool. The prompts are phrased honestly, asking for a real comparison of strengths and weaknesses. No spin, no leading questions.
The Thinking Behind It
Comparison pages are one of those things every SaaS builds, and most of them read like thinly-veiled sales pitches. Everyone knows it. The visitor knows you cherry-picked the feature matrix. You know they know. It's this weird dance where nobody trusts the content but we all pretend it's useful.
I figured: what if I just... gave them an exit ramp to verify my claims independently? If FlareWarden is actually good for the use case I'm targeting (small to medium businesses that want simple monitoring without enterprise complexity), then AI tools trained on the broader internet should reflect that. And if the AI says the competitor is better for their situation, that's genuinely useful for the visitor — and saves me from acquiring a customer who'd churn anyway.
It's a small bet that transparency converts better than persuasion. We'll see if the data backs that up.
The Less Glamorous Part of the Day
Before that, my morning started with debugging a passkey deletion flow. Passkeys are one of those features where the spec is elegant and the implementation is full of weird edge cases. The delete confirmation modal had a subtle bug — the UI framework I use lowercases attribute names behind the scenes, so the signal binding for the "type to confirm" input wasn't matching what the disabled-state check was looking for. Classic case of two systems each doing something reasonable that breaks when they meet.
The fix itself was small, but I also added something I'd been putting off: after you delete a passkey on the server, the browser should also be told to forget it. There's a WebAuthn Signal API for this — signalUnknownCredentialId — that tells the authenticator device "hey, this credential doesn't exist anymore, stop offering it." Without that call, your password manager or device keeps suggesting a passkey that no longer works. It's one of those invisible polish things that nobody notices when it works, but would absolutely frustrate someone who hit it.
Reflections
Days like yesterday are why I enjoy solo building. One commit is a marketing experiment that might change conversion rates. The other is a three-file bug fix that makes the product slightly less annoying for the handful of people using passkeys. Neither is a big deal on its own, but the cumulative effect of shipping both in the same morning — without a sprint planning meeting or a Jira ticket — is the whole reason I'm doing this.
The frustrating part is still the same as always: there are ten things I want to build for every one thing I actually ship. The comparison page AI links took longer than expected because each competitor page gets a unique prompt tailored to that specific matchup. Seven competitors, three AI tools, each with a different question. It's the kind of detail that probably doesn't matter but felt right.
Tomorrow I'll probably be back to something completely different. That's the job.
Yesterday was a mix of building something cool and immediately breaking it.
Passkey authentication
I added full WebAuthn passkey support. Register a passkey, log in with it, delete it with a type-to-confirm modal. Passkeys get smart names based on the authenticator type: "Cloud Passkey" for synced ones, "Security Key" for USB keys, "Phone Passkey" for cross-device, etc.
Shipped it. It was broken in production.
The login page was throwing 500s for everyone, not just passkey users. Turned out to be a chain of bugs:
WebAuthn fields needed base64url decoding, not just a type cast — so the binary data was garbled
The AAGUID (authenticator identifier) is raw bytes that can contain null bytes, which SQLite over Turso's protocol rejects as invalid UTF-8
Origin validation was failing because our BASE_URL didn't include the app. subdomain where auth actually lives
Four commits to fix what one commit introduced. Classic.
Email verification is less annoying now
Instead of a persistent banner nagging you to verify your email, the prompt now appears when you try to add a website. Tied directly to the action, not just floating there being ignored.
Also built a centralized email queue system while I was in there. All emails now go through a queue table with priority, retry with exponential backoff, and dead-letter support. Single machine processes it globally at Resend's rate limit. If the queue insert fails, it falls through to direct API — belt and suspenders.
A11y & SEO sweep
Fixed WCAG AA color contrast failures across the site
Removed incorrect ARIA tab roles from decorative elements
Added proper aria-controls to functional tabs
Fixed heading hierarchy (decorative h3s → p tags)
Added llms.txt and llms-full.txt for LLM-readable product info
OpenAPI spec for the status page API
Welcomed AI crawlers in robots.txt
16 commits. Most of them fixing the thing I just shipped. That's the game.
Hey IH — back with an update 👋
Started the painful process of submitting to multiple SaaS directories. Most seem to operate the same way, asking for basic information, logo, screenshots, etc.
Then you enter a queue and at some point you will be promoted when that queue position is hit. And there is a upsell to a promotional "jump the queue" plan that gives you exposure faster, and more prominent positioning.
In my other company, we didn't go through this, and largely relied on Facebook Ads (first month) and SEO. To this day my other company is 100% SEO traffic, no ads, no marketing, and it's going great because the niche is small enough.
This is a much broader niche, with lots of overlap. Even when I have "done this before" it still feels like I have a lot to learn because of the difference just in the category.
Hey IH — back with an update 👋
Last time I introduced FlareWarden and talked about Smart Setup — how it scans your site and auto-detects dependencies, content to monitor, and builds out your whole monitoring config from a single URL.
The problem: you had to sign up to see any of that. So we built "What Can I Monitor?" — a free, no-signup tool that lets you paste any URL and instantly see what Smart Setup finds.
It scans your site and shows you:
Dependencies it detects (Stripe, Cloudflare, Vercel, analytics providers, CDNs — 700+ services)
Content monitors it would set up automatically (key elements on your pages that matter if they disappear)
The full picture of what's actually running under the hood of your site
Most monitoring tools make you configure everything manually and hope you didn't miss something. We wanted to flip that — show you what's there first, then let you decide if it's worth monitoring.
The thing I think will surprise people: you're probably relying on dependencies you've forgotten about. A payment widget loading from a third-party CDN, an analytics script you set up a year ago — that stuff goes down silently until customers start complaining.
No account needed. No email capture. Just paste your URL and see what comes back.
👉 flarewarden.com/what-can-i-monitor
If you try it, I'd love to hear: did it catch everything? Did it miss something? This is still early and your feedback directly shapes what we build next.
And if you missed it — the founding member deal (40% off forever) is still open until June 1. But try the tool first. That's the whole point.
Hey IH 👋
I built FlareWarden for people like us — founders running real businesses who don't have time to babysit a monitoring dashboard.
I'd love to invite this community to use it. The free plan is permanent (15 monitors, SSL monitoring, status page, no credit card) and if you want more, founding member pricing locks in 40% off forever if you sign up before June 1.
What makes it worth trying:
Paste one URL. Smart Setup scans your site and auto-detects your dependencies (Stripe, Shopify, Cloudflare, 700+ services), sets up content monitoring, and generates a branded status page. About 2 minutes to go from zero to fully monitored.
The part I think IH founders will appreciate most: we cross-validate from up to 18 regions before sending an alert. A network blip in one location won't wake you up at 3am — we confirm it's real first.
We also link your site to its dependencies with a parent/child architecture. If Stripe goes down, your monitor shows "degraded" so you know checkout is broken before customers start reaching out.
Come kick the tires. I'm actively building this and genuinely want feedback from people who run their own stuff. What's missing? What would make this the tool you actually keep using?
Drop your project URL in the comments and I'll show you what Smart Setup detects — dependencies, content checks, the whole picture. Curious to see how it handles what you're all building.
Comment