We spent a week submitting our product to directories — G2, Capterra, Crunchbase, a dozen others. Six days in, we renamed the entire product and moved it to a new domain.
Not ideal timing. But the alternative was worse, and the whole thing taught us more about our own stack than the previous six months had.
The original name was Randi. In Norway, that's a traditional woman's name — the local equivalent of calling your product Emma or Ingrid. It sounded warm and human rather than like another AI tool with a dropped vowel. It tested fine with us, and it shipped.
Then we found out what it means elsewhere. In UK slang it's a crude adjective. In Hindi it's a slur for a sex worker. We'd been marketing to an international audience under a name that was, in two large markets, somewhere between a joke and an insult.
Here's the trap, and it's why I think this is worth writing up: the name wasn't invented, so it never felt like it needed vetting. It was a real word in our own language with an obvious, wholesome meaning. That's exactly the category of name that doesn't get checked — you check made-up names for accidental meanings, not your grandmother's.
And nobody had told us. That's the part worth sitting with — if your name has a problem in a language you don't speak, you will not get a bug report about it. You'll just quietly underperform in those markets and never know why.
The new name is Inwista. This time we ran it through a multilingual slang check before committing, which is a step we should have had the first time and now never skip.
Timing logic: brand equity only compounds. We had a small amount of it and a link-building sprint about to build more, all pointed at a name we'd have to abandon eventually. Renaming while you're small is cheap. Renaming at 10x is not.
One principle for the whole migration: add → verify → flip → redirect. Never remove.
Every new surface went live and got verified working before the old one changed. Nothing was deleted. The old domain still resolves, still redirects, and auto-renews forever.
That meant the actual flip was reversible in seconds — the redirect is a single Cloudflare rule we could disable if it went wrong. It's the difference between a scary migration and a boring one.
1. OAuth hung forever, with no error. Our backend has a FRONTEND_URL config var. It turns out that isn't just used for email links — it's the postMessage targetOrigin in the OAuth callback. If it doesn't match the domain the user is actually browsing, the popup's message gets silently dropped and the integration flow hangs. No exception, no log line, nothing server-side. Just a spinner forever.
The lesson generalises: FRONTEND_URL means "the domain users browse", not "the frontend's name". And config vars agreeing with each other is not the test.
2. Config var changes restarted prod instantly. We assumed changing config vars staged the change for the next deploy. They don't — the dyno restarts immediately. So production briefly ran new config against old code, which is exactly the broken-OAuth window from point 1. Found in production, which is the expensive way to find it.
3. Our find-and-replace skipped two file types. The sweep covered 1,700+ files but missed .mts and public/. Result: the live sitemap advertised 368 URLs on the old domain for a day, plus a stale robots.txt. Canonicals were fine — the config that generated the sitemap wasn't.
4. A blind replace nearly deleted our own CORS origins. The sweep helpfully replaced the old domain inside our productionOrigins array — which would have removed the live site's own origins on deploy and broken it for every existing user. Caught in review. The correct state was to have all four origins (old + new, apex + www) coexisting for years, not to swap them.
5. Webhook headers are an API contract. The sweep renamed our outbound webhook headers from X-Randi-Signature to X-Inwista-Signature. That's a breaking change for anyone verifying signatures. Fix: dual-send both header sets, and drop the old ones only once customers have migrated. Same pattern applied to our generated caption tracks, where a rename would have created duplicate tracks on YouTube and then a 409.
This list matters more than it looks:
localStorage keys. Changing them would re-trigger every dismissed banner and onboarding redirect for existing users.
postMessage protocol strings. They have to stay in sync across two repos; the string is a protocol, not branding.
Blog post slugs containing the old name. Renaming those breaks the links twice — once now, once for anyone who linked to them.
Internal env var names, Heroku app names, GitHub repos. Zero user-visible benefit, non-zero chance of a 3am outage.
The legal entity. Marketing copy dropped it, but invoices, terms and payment-processor records keep it until the registration actually changes.
The rule we ended up with: rename what users read. Leave what machines depend on.
Finnish inflects. "Randiin" (illative case) does not become "Inwistain" — it's "Inwistaan". A naive replace produces a word that's subtly wrong to every Finnish reader.
Never blind-replace a lowercase brand name. Ours appears inside ordinary French words — grandir, agrandissez. A regex would have quietly mangled the French site.
And "a Randi" became "a Inwista" in five places. Vowels change your articles.
Yes, and sooner. The rename cost us about a week of focus and a temporary dip in search performance we're still riding out. Keeping the old name would have cost us two markets permanently.
And if your product name is an ordinary word or name in your own language — especially if it's a warm, obvious, unremarkable one — that's precisely when to go check it in the languages you don't speak. Invented names get vetted. Familiar ones don't.
We're Inwista — transcription and subtitles in 70+ languages, plus a video studio, all processed on our own EU servers. Formerly Randi, obviously.