How we audited every claim on our website (and what we found)

The starting point

OmniWatchGuard grew fast over a few months — new features, new pages, new copy every sprint. At some point I realized I no longer knew, without checking the code, which claims on the site were true and which had been left over from the planning phase.

It wasn't a deliberate decision to lie. It's the kind of drift that happens naturally in a solo-founder product: you write copy for a feature before building it, put it on the roadmap, then in the rush to ship other things, the copy stays unchanged for months.

The process: how we found the gaps

We didn't start from a list of suspicions. We started from a simple question:does every file that generates public content — pages, FAQ components, JSON-LD schema, the pricing calculator — match what actually exists in the code?

1. Listed every file producing copy visible to users or search engines: FAQ.astro, FAQSchema.astro, FAQEnterprise.astro, PricingSchema.astro, Comparison.astro, Calculator.astro, SoftwareAppSchema.astro, AggregateRatingSchema.astro, privacy.astro
2. For every functionality claim ("supports X", "monitors Y"), checked for the actual implementation in the backend/crawler
3. Classified each claim into three buckets: true (implemented and tested), partially true (implemented with unstated limitations), false (roadmap-only or never built)
4. For every false or partial claim, picked one of two actions: correct the copy to match reality, or build the feature so the copy becomes true

What we found

Hardcoded ratings and testimonials

AggregateRatingSchema.astro and Testimonials.astro had a fixed 4.9 rating, a fixed "200+ reviews" and "500+ companies" claim, plus testimonial names and quotes written directly into the code — those customers didn't exist. We replaced all of it with real data computed from the reviews database table: real average rating and review count, with the testimonials section hiding itself if there are zero real reviews yet. The "leave a review" CTA stays visible permanently.

Roadmap features presented as live

Login-page monitoring, RBAC (roles and permissions), and SSO appeared in the FAQ and comparison table as available features. They weren't. We corrected all six affected files (FAQ, FAQSchema, PricingSchema, Comparison, Calculator, SoftwareAppSchema) to clearly show "Roadmap 2026" for RBAC/SSO, and removed entirely a claim about iOS/Android apps that didn't exist and weren't planned.

A rendering bug that hid a real problem

The homepage's Comparison.astro component had a rendering bug that showed a green checkmark (✓) for every feature regardless of the actual underlying data — including features competitors had and we didn't. The comparison table was effectively lying because of a technical bug, not just stale copy.

Why we chose to build the feature, not just fix the copy

For login-page monitoring, we had a choice: fix the copy (fast, about an hour of work) or actually build the feature (more effort, but fixes the problem at the root). We chose the second option. We added an encrypted (AES-GCM) column for the auth cookie/header on the monitors table, the crawler decrypts and injects the header on both fetch paths (plain and Puppeteer), and detects session expiry via a 401/403 or a redirect to a login-like path. We tested it end-to-end against OmniWatchGuard's own dashboard (which usesAuthorization: Bearer, not a cookie) before republishing the copy as true.

What stayed unchanged

Not everything we found incomplete got fixed by building it. RBAC and SSO remain a genuine 2026 roadmap item — marked as such, without ambiguity, and we don't promise an exact date until we've actually started work on them.

Frequently asked questions

Why publish this instead of quietly fixing it?

Because the process itself is useful to other solo founders hitting the same natural drift between roadmap and marketing copy, and because transparency about what's true today builds better trust than any testimonial.

How do you prevent this from happening again?

There's no fully automated process yet that prevents the drift entirely — it's a structural risk in any fast-iterating product. What concretely changed: ratings and testimonials can no longer be hardcoded (they come exclusively from the database), and any new feature mentioned in copy goes through a manual check against the code before publishing.

Did the audit cover the English pages too?

Yes, every fix was applied symmetrically to both the RO and EN versions of each affected file, including the JSON-LD schema used by search engines.