One click too early

For two working sessions I believed Google had a bug. My app's sign-in screen was supposed to show "Duskglow" and a logo on Google's consent page, and instead it showed a raw infrastructure domain. The button that should have submitted the branding for review was nowhere on the page. A forum thread full of people who also couldn't find it looked like confirmation. I wrote the whole thing down as a platform outage and planned to check back weekly. Today I learned the control was one click away the entire time, behind an info icon, and what it said changed the shape of the product's front door.

What the info icon said

The panel behind the icon was not a bug report. It was a review verdict, and the verdict was correct: "Your home page is behind a login page." A reviewer opening my site with no account got a date-of-birth form, then a sign-in button, and nothing on either screen said what the app was. From Google's side, I was asking for a branded consent screen for a product that refused to describe itself.

The fix was obvious once the finding was visible. Build a real home page. What the finding did not do was tell me how much of my own thinking had been resting on an assumption I never tested.

I want to be precise about how the misread happened, because it wasn't laziness. I had read Google's documentation. I had checked every configuration field. I had verified the domain in Search Console under the wrong account, found that, and fixed it. Each of those was real work, and each one narrowed the search in the wrong direction, because every check I ran assumed the control was missing rather than hidden. The forum thread made it worse, not better. Ten people failing to find a button is evidence that the button is hard to find. I read it as evidence that the button did not exist.

So the rule I'm taking from this: before declaring an outside platform broken, click every info icon, open every side panel, and exhaust the page's own ways of telling you something. A platform that has a problem with your submission usually says so somewhere on the page. It just doesn't say so where you're looking.

The gate that had to move

The home page decision sounds like a copy task and was actually a compliance decision, which is why I slowed down on it.

Duskglow is an AI companion for adults. The age gate has always been the first thing anyone sees, before the sign-in screen, before anything. That ordering came from a principle I still hold: a companion product should never let an unverified user reach the companion, or an account, without passing the gate. A public landing page that renders before the gate looks, at first glance, like it weakens that.

It doesn't, and working out why was the real product thinking of the day. The gate protects two things: the interaction with the companion, and account creation. Those are what the age-related laws for AI companions attach to, and those are what a child could be harmed by. A static page that describes the product, links the privacy policy, and states plainly that the app is for adults 18 and older is not the companion, and it collects nothing. Moving the gate from "first thing on the site" to "the moment you tap Sign in" keeps it in front of every account and every message. What changes is that a curious visitor, a reviewer, or a parent can read what the thing is before being asked for a birth date.

I looked at three other shapes and rejected them for reasons worth naming. Adding a description to the sign-in screen itself fails because the birth-date form still renders first, and a form hides information exactly the way a login does. A separate "about" page with the registered home-page link pointed at it leaves the actual root of the site as a login page, which is the thing the reviewer objected to. Splitting into a marketing domain and an app domain is the pattern the well-known privacy products use, and it is the right long-term answer, and it costs a second domain, new redirect entries, and app-install changes for no gain the review needed today. Deferred, not rejected.

The copy on the landing page was its own small discipline. Every sentence about data is a paraphrase of a sentence already live in the privacy policy, in the same generic language. No new claim got introduced on a marketing surface that the policy hadn't already made. I wired the same forbidden-phrase check that guards the policy text to guard the landing text too, so a future edit to either page trips the same wire.

Cheap test before expensive hedge

One more premise nearly cost me a deploy cycle, and I want to record it because I caught it in time rather than after.

While preparing the ship I found a community post from a developer whose home page kept failing the same review. His page was rendered entirely in the browser by JavaScript, the raw HTML was empty, and the failure only cleared after he added server-rendered text. My landing page is also rendered in the browser. My design notes had listed exactly this as the one way the plan could be wrong.

The tempting move was to build the fallback right away: pre-render the landing into the raw HTML before shipping, so a checker that never runs JavaScript would still see the text. A preview cycle, maybe an hour, and a small first-paint compromise for signed-in users. Reasonable insurance.

I shipped without it. The reasoning was about sequence, not confidence. Requesting re-verification was free and, per Google's own documentation, takes minutes. Building the fallback took an hour and would have been built on a guess about how Google's checker works. If the cheap test failed, I'd build the hedge with a real error message in hand. If it passed, I'd have saved the hour and avoided carrying a compromise I didn't need.

It passed in under ten minutes, on the browser-rendered page, and the fallback never got built. The forum post was true for that developer's page and irrelevant to mine, and I had no way to know which without running the test. A published counter-example is a reason to update a probability. It is not a verdict.

Mental Models

Exhaust the page before blaming the platform. When an external service seems to be missing a control, open every info icon and side panel first. Other people failing to find it is evidence it is hidden, not evidence it is absent.

Ask what the gate protects, then move the gate, not the protection. An age gate exists to keep unverified users away from the companion and from account creation. A public page that offers neither can sit in front of it without weakening it.

Verify the instance, not the class. Documentation describes what a platform does in general. Your account, your plan, and your page are specific, and the specific case is the one that ships.

Run the free test before building the insurance. When a cheap, fast check will tell you whether a hedge is needed, run it first. Hedges built on guesses cost twice: once to build, and once to carry.