The landing page wasn't converting installs
The old BinderDex homepage was built to explain a web product. The product is a mobile app now, and "sign up on the web" is the wrong funnel. Yesterday's rebuild rips out the founder note and web-companion sections and replaces them with a numbered, scroll-to-install landing page patterned after the one that already works for StatPro.
The hero section leads with a binder-first headline over a phone frame rendering a real published binder page (a CSS grid, swappable for a screenshot later). Below it, a live stat strip pulls prices-refreshed, cards-tracked, and published-binder-idea counts from a new getMarketingHeroStats() query. One round-trip, and if the database is cold the strip falls back to static copy so the page still renders. Store badges and a desktop QR code close the hero.
The /download route is the quiet keystone. One URL serves both stores: it 302s based on user agent, with Vary: User-Agent and Cache-Control: private, no-store so a CDN can't replay an Android redirect to an iPhone. Campaign tokens on the store URLs give attribution without polluting the canonical URLs used in JSON-LD and analytics.
E2E: the auth fix that was breaking every test
Separately, SDK 57's dev client started identifying itself with http:// origins where the old exp:// scheme was blanket-trusted. Sign-in would 403 with INVALID_ORIGIN about half the time depending on which URL form the launcher used. The fix trusts localhost, 127.0.0.1, and the LAN IP on port 8081 (LAN IP computed at runtime), plus 10.0.2.2 for the Android emulator. Proven by curl bisect: 403 before, clean past origin after.
We also tried two-sim sharding to speed up the suite. Measured it carefully: two dev clients sharing one Metro host ran flows 4-6x slower (71 minutes vs 16.5 serial). Rejected it. Sometimes the fancy approach loses.