One Account Owned Every Console. The Fix Was a Second Owner

I opened the week with two questions I had been carrying for a while instead of a build. Neither was about a feature. One was about a name, the other about who owns the keys, and the second one turned out to be the most important thing I did all week.

The name that didn't matter

The repository and the hosting project still carry the name I gave them in April, with a version suffix that stopped meaning anything months ago. I wanted to know whether to fix it now and whether leaving it would cost me later.

Honest answer: it costs about the same whenever I do it. I looked at what a rename touches on both platforms, and nothing a user sees has pointed at the old names since the real domain went live. So: not before the beta, and no regret about waiting.

What interested me more was the reason I had written down for not renaming. It cited a preview-address rule that made a rename risky. I removed that rule two weeks ago while closing a different security finding, and the sentence citing it just sat there, still sounding like a decision. Nobody re-read it because it was tidy. The reason outlived its fact.

I corrected the sentence. The lesson is bigger than the sentence. When you write down why you are not doing something, you have created a thing that can go stale, and stale reasons are harder to spot than stale facts because they still read as judgment.

One account held every key

Question two sounded like housekeeping. I built Duskglow signed in with my personal Google account, and since then I have set up a proper work account that sends the Duskglow email. Should I move everything over?

Framed that way it is a question about tidiness. Framed as a failure walk it is something else. The cloud project that holds the sign-in registration, the key backup permission, and the model's API key with its prepaid credits sat under one personal account. So did the database, the hosting, the source code, and the AI assistant I build with. If that one account were locked, phished, or lost, every one of those would go at the same time.

The sign-in registration is the part that scared me. A new one is not a quiet replacement. Rebuilt in a new project, it would most likely mean every user approving the app again, and the brand check that lets Google show the product's name at sign-in belongs to the project, so that would start over too. For a journaling app whose whole premise is that your entries are yours, "please sign in again and re-approve us" after an outage I caused is a trust event, not a technical one.

Two owners, not a swap

My first instinct was the swap: move everything to the work account and be done. That instinct was wrong, for a reason I only saw when I walked the same failure the other way. The work account exists only while I pay for the subscription behind it. Swapping would trade a single point of failure for a different single point of failure, one with a monthly bill attached.

Two owners is the shape that holds. The personal account stays, the work account joins it as a full owner on every console but one, and losing either account alone no longer locks me out of anything that holds user data. It took one sitting across four vendors. One vendor does not let you change the login email at all, so that one stays where it is; it holds no user data, so losing it would cost me convenience, not anyone's entries. Google's own docs count it as an advantage when a project belongs to an organization rather than to the person who created it, which is where this one should end up. Moving it back out afterwards takes a support request, and I do not yet know what the move does to a verified sign-in screen, so it waits until after the beta.

Moving a date

The week's one build was not a feature either. The beta start moved from October 26 to November 2, which was free to do only because the invitations had not gone out yet. Once a tester holds a date, it is theirs.

What surprised me was how many places the date lived. The sign-up page had it in five schedule rows, a headline, and a test. The welcome email had it in the subject, the preview line, the opening, and three rows. Two send scripts, seven plain-text messages, the sign-up form's description and one of its questions, and the queries that will read the results all carried it. More than twenty spots for one Monday, most of them written out by hand because they are meant to be read by a person, and all of them had to agree.

The one document that did not change was the privacy policy. Its retention promises are written as periods after an event, thirty days after the round fills and ninety days after the window ends, not as calendar dates. When the window moved, the promises moved with it and the words stayed true. One line in a rejection reply had said answers would be deleted "when the beta ends in November," which was now wrong, and it became "within a month, by early December."

On the phone, the page change checked out, and it ships when I say so. The emails are updated in their files and will get a fresh test send before anyone receives one.

Mental Models

A written reason can outlive its fact. When you record why you are not doing something, re-read it whenever the thing it points at changes. Tidy prose hides stale judgment better than stale data does.

Walk the loss before you decide the ownership. "Should this be under my work account?" is a tidiness question. "What breaks if this account vanishes tonight?" is the real one, and it gives a different answer.

Add an owner, do not swap one. Every single account is a single point of failure, including the one that looks more professional. Two owners cost one sitting and remove the lockout wherever a vendor allows a second owner, instead of moving it somewhere else.

Promises as periods, not dates. A promise written as "thirty days after X" survives every schedule change. A promise written as a date has to be found and fixed in every copy, which is why the one reply that carried a date was the line I had to rewrite, and its new wording still names a month, so it will need the same care next time.