Rebuilding the Daily Sudoku landing page after the Play Store launch

The app shipped on Google Play on July 10. Four days later, the landing page still said “Out now” next to a generic phone mockup, the JSON-LD claimed iOS and Web support that did not exist, and the download button sat below the fold on a laptop. The page was not broken. It was just not doing its job.

What follows is what we changed in one session — not a rebuild from scratch, but a new version of the existing home, keeping the same route, the same i18n structure, and the same shared layout system. The entire session was pair-programmed with an AI coding assistant, and the design review was run through Impeccable, an open-source design critique and iteration tool for frontend interfaces.

The problem was not aesthetics, it was honesty

The old page looked fine. Warm cream background, Fraunces headline, purple accent that matched the game. But a visitor deciding whether to install had to deal with three things that were not true:

1. The JSON-LD declared operatingSystem: "iOS, Android, Web". The only store button pointed to Google Play. An iPhone user might infer the app was available and hit a dead end.
2. The trust bar said “5 / Difficulty levels”, “Offline / Play without signal”, “Saved / Resume any board”. Those are features, not trust signals. They occupy the most valuable real estate on the page — right after the hero — without reducing install risk.
3. The hero headline was hardcoded in English inside the Astro component. The Portuguese version had a different headline in the content file, but the component ignored it.

Each one is small. Together they make the page feel like a placeholder that nobody reviewed after launch.

What we kept and what we removed

The page already had the right bones: a shared BaseLayout, Header, and Footer from @apps/site-ui, bilingual content in src/content/landing/, and a content.config.ts schema that validated every field. We kept all of that.

Two sections were not earning their space:

• “How it works” — three numbered steps (Download, Choose difficulty, Play offline). This is the generic 3-step landing template. Nobody needs instructions for installing a free app.
• “Founder” — a section about the studio. It belongs on the institutional site, not on a conversion page where the job is to get someone to tap the Play Store button.

We kept the FAQ because it answers real pre-install questions: offline play, saved progress, beginner support, credit restoration. The credit answer is unusually honest for a mobile game landing page, and that honesty does more work than a founder bio.

Screenshots are the proof, not decoration

The old page used a single app.png placeholder illustration. We took two real screenshots from the running game — one of the board mid-game, one of the home screen — and placed them in the hero phone mockup and a new showcase section.

The device mockup is the signature component: near-black frame, oversized rounded corners, real screenshots. If a section can use a real screenshot, it should, before any abstract panel or decorative grid. The game’s visual identity — the Editorial Ink direction we described in giving a Sudoku app a real art direction — carries over to the site through the same semantic tokens.

We also fixed the alt text. Both screenshots were using the same ariaLabel from the content schema. We added a homeAriaLabel field so each screenshot describes what it actually shows. “Daily Sudoku home screen with Continue, New Game, Daily Challenge, and Statistics actions” is more useful than a generic “Daily Sudoku screenshot.”

The header was lying about its width

The shared Header component renders with container-shell, which limits content width and centers it. Correct for the brand and nav links. But we had applied the background, border, and shadow directly to body > header, so the visual bar stopped at the container edges instead of spanning the viewport.

The fix was a ::before pseudo-element with width: 100vw behind the content. The header content stays containerized; the visual treatment goes edge to edge. This is the kind of bug that looks broken on a wide screen but passes on mobile, where the container nearly fills the viewport.

Theme toggle and sticky header

The Sunstone Apps institutional site already had a light/dark toggle in its header. The Daily Sudoku site did not. We reused the same shared ThemeScript and ThemeToggle from @apps/site-ui, with a site-specific localStorage key.

The CSS had to change too. The old dark theme was driven by @media (prefers-color-scheme: dark), which means the toggle would fight the OS preference and lose. We replaced every prefers-color-scheme rule with :root[data-theme="dark"] so the toggle actually controls the palette.

The header is now sticky, with a translucent background, backdrop-filter: blur(18px) (prefixed -webkit- for Safari/iOS), and a ::before full-bleed bar. The toggle sits in the header’s actions slot, so it follows the user through the page instead of disappearing after the hero.

The critique loop

We ran the Impeccable design critique after the first pass. Impeccable is an open-source tool that scores frontend interfaces against Nielsen heuristics, runs a deterministic anti-pattern detector on CSS/HTML, and can inject a live overlay into the browser for visual inspection. Score: 29/40 — strong visual foundation, conversion and clarity gaps.

The AI assistant generated the initial CSS and component code, but it was the critique loop that caught what raw generation missed:

• The hero headline scale pushed the CTA below the fold on a 900px laptop. We dropped the clamp() ceiling from 7.8rem to 6rem.
• The trust bar repeated the same promises as the hero, showcase, and features. We reframed it from features to proof: “Google Play / Published Android app”, “Offline / Puzzles stay available”, “No account / Start without setup”.
• The JSON-LD said iOS, Android, and Web. We changed it to Android, and added a FAQ item: “Where can I download Daily Sudoku? — Available for Android on Google Play. iOS is not listed on this page today.”
• The muted text color #78716C measured 4.2:1 contrast against the warm background — below WCAG AA. We darkened it to #5F5650, which measures 6.4:1.

The critique also flagged the theme toggle touch target at 40x40px. The minimum is 44x44. We fixed it in the shared component, so the Sunstone Apps site got the fix for free.

After the critique, we ran the layout command. The main issue was rhythm: every section had the same structure, and the features grid was six identical cards.

We introduced a bento layout for the features. The first card is larger, spans two columns and two rows, and has a subtle Sudoku grid motif in its corner. The remaining cards fill in around it. This breaks the “identical card grid” pattern without abandoning the grid system.

We also added a secondary CTA in the hero. The primary button goes to Google Play. The secondary button — “Read practical details” / “Ver detalhes práticos” — scrolls to the FAQ. Visitors who are not ready to install can answer their questions without leaving the page.

Browser compatibility warnings that mattered

Two warnings from the Edge DevTools compatibility panel led to real fixes:

1. backdrop-filter without -webkit- prefix. Safari and iOS Safari need the prefixed version. We added it everywhere backdrop-filter appears — in the Sudoku site, the Sunstone Apps site, and the shared contract.css.
2. color-mix() without fallback. Chrome before 111 does not support color-mix(). We added a fallback declaration before each color-mix() call in the shared contract and the site CSS. The fallback uses a solid token value; the modern declaration overrides it in browsers that support color-mix().

One warning we did not fix: the color-mix() on .eyebrow in the shared contract. The Edge Tools kept flagging it even with a fallback. We removed the color-mix() from that rule entirely and kept the solid token. The visual difference is negligible, and the warning is gone.

How AI shaped the session

The entire rebuild was pair-programmed with a Claude-based coding agent. The AI generated the initial Astro component rewrite, the CSS system, the content schema additions, and the bilingual copy. A human reviewed the output in the browser, caught the header width bug visually, and pointed out the missing nav links and compatibility warnings from Edge DevTools.

The most useful part was not generation — it was the evaluate-then-fix loop. The AI ran Impeccable’s critique, layout, clarify, and polish commands sequentially, each one consuming the previous snapshot as its backlog. That loop found the contrast failure, the touch target, the JSON-LD mismatch, and the repeated trust bar copy. Without it, the page would have shipped looking polished but lying about its platform and failing WCAG AA on body text.

The AI also validated every change programmatically: Playwright measured overflow, CTA position, theme toggle state, and data-theme persistence at mobile and desktop widths. That is faster than manual QA for layout regressions, though it does not replace checking the page on a real phone.

The indexing and metadata lessons from this session connect to earlier work we documented in Google indexing checklist for Astro sites on Cloudflare Pages — the JSON-LD and platform alignment fixes here are a direct consequence of what that checklist taught us.

What we would still change

The page is better, but it is not done. The critique raised questions we have not answered:

• Should the hero mockup show the “continue saved game” moment instead of only the board? That is the strongest differentiator, and the current screenshot shows a board mid-game, not the resume flow.
• What does a player who already has three Sudoku apps learn in 10 seconds that makes this one worth installing? The page still leans on baseline promises: offline, saved progress, calm UI. A comparison or a “why this Sudoku” section might answer that.
• Is the premium aesthetic supposed to feel like a calm puzzle notebook or a serious daily brain-training product? The answer changes typography density, proof strategy, and CTA rhythm.

Those questions are for the next pass. The current page is honest about its platform, its CTA is visible on a laptop, its screenshots are real, and its theme toggle works. That is a meaningful step from “not broken” to “doing its job.”