We went OAuth-only for two days, then partly changed our minds

For a couple of days, the only way into CreatorOS was Google or Discord sign-in. We'd removed email/password entirely — no password field anywhere in the app. The reasoning at the time was real: without a purchased domain, we couldn't get a verified sending domain from our email provider, which meant password reset and verification emails either wouldn't send reliably or would be badly rate-limited. Rather than ship a half-working password flow, we cut it and leaned on OAuth, which doesn't need us to send email at all.

Then we bought creatoros.onl, which is a small, deliberate exception to a rule we're otherwise strict about (more on that in a separate post) — until there's a paying customer, we don't spend money on the product. But a real domain unblocks two things at once: a verified email-sending domain, and satisfying Google's OAuth verification requirement that the app link to a real homepage. Both blockers were domain-shaped, and once the domain existed, neither one applied anymore.

Restoring the option, not replacing anything

So email/password came back — pulled from git history and merged with everything we'd built during the OAuth-only window (Discord sign-in, the Resend audience sync, the `plan` field), rather than reverting any of that work. Google and Discord still sit above the divider on the login and signup screens as the recommended path; email/password is now a third option below it, not a replacement for the other two.

The honest version of this story isn't "we made a mistake and fixed it." Going OAuth-only was the right call given the constraint we had at the time (no verified sending domain). Bringing password auth back was also the right call once that constraint lifted. Product decisions made under a real, temporary limitation are allowed to change when the limitation goes away — the mistake would have been treating a workaround as a permanent architectural stance.

Want to see what we’ve actually built?