Why I'm Telling Visitors to Ask AI If My Competitor Is Better
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.
