We audited our own website and found it was selling the wrong app version

Yesterday we pointed an autonomous QA auditor at our own public website — every public route, every download link, every page’s design — and told it to fix what it found without asking permission. It found plenty.

The most embarrassing find

Our Android download page was selling v1.2 of the Merchant app. Version 1.3 — with native Google Sign-In, the fix for the login bounce everyone complained about — had been released, published on GitHub, checksummed, and announced. But the download button on our own website still pointed at the old APKs.

A customer who trusted our site over the GitHub release page would have installed the version with the bug we just fixed.

What the audit found

Stale download links. The /android page hardcoded v1.2 APK URLs. There was no single source of truth for “what’s the current version” — just strings pasted into HTML.

Three design systems. The landing page speaks indigo (#4f46e5) with Inter typography and a sticky blurred nav. The info pages (/android, /privacy) spoke teal (#0f766e) with system-ui and no navigation at all. The dialer pages speak cyan on dark. Same company, three brand colors, no shared header.

Orphan pages. We had built a /releases page and a version-history.json config file — then never wired them up. They existed in the repo, served to nobody. The privacy page had no footer. The data-deletion page wasn’t in the sitemap, so search engines didn’t know it existed.

Zero breadcrumbs. Not one breadcrumb trail anywhere on the site.

What we fixed (all live today)

• /android now serves v1.3 — correct APKs, correct checksums, correct “What’s new”
• New /releases page — full version history with download links for every release, wired into the sitemap
• New /version-history.json — a single machine-readable source of truth for the current version, served live
• Design unification — all info pages now use the landing page’s indigo/violet tokens, sticky nav header, and branded footer
• Breadcrumbs on every info page, contextual CTAs (/android → /releases), and the missing /data-deletion sitemap entry

All 137 automated tests pass. The deploy is live.

What we learned

The root cause wasn’t laziness — it was no single source of truth. The version number lived in three places: the Android build.gradle, the GitHub release, and the website HTML. When v1.3 shipped, two got updated. The website didn’t, because nothing forced it to.

The fix isn’t just “update the link.” It’s the /version-history.json — one file that the download page, the releases page, and any future integration all read from. Next release, we update one file.

The design drift happened the same way: each info page was written standalone, copying an old template, with no shared component. Now they share the landing page’s tokens and nav. Drift is still possible, but at least there’s a standard to drift from.

We’re running this audit hourly now — incremental checks, incremental fixes, shipped straight to production. If the site ever sells the wrong version again, we’ll know within the hour.

---

Found something we missed? The release history and Android download pages are the best place to verify you’re on the latest version.