A trademark conflict does not negotiate, and trademark law seems ambiguous at best. So when I was looking to trademark my company name and found another online entity with the same name, that while not a SaaS, sold client side software, I was pretty crushed. It took me a while to come to terms with the idea that I would most likely have to change the company name. I paid a lawyer to investigate the feasibility and it was 50/50 at best of getting the trademark. Not because of this specific company, they operated outside the US, but the terms I was using for the company name were so overly saturated in the field that it left significant doubt on whether we could get it approved or not.
So I had to rename the company, its domains, its Okta Identities, Google Workspace and its GitHub organization, and I wanted to do it as quickly as possible. The reason it only took 24 hours instead of however long these things potentially can take is twofold. The first reason is that we had not launched as of the finding, we had a public website with documentation, but no active customers, no ToS and Acceptable Use agreements that needed renewing. The other factor was a bet I placed weeks earlier, back when a rename was still hypothetical and I had no reason to think it would ever be anything else. The bet was that no domain literal and no brand string would ever exist in code, anywhere, zones enter through variables, per-environment domains are registry rows, and brand-prefixed event strings live behind exactly one constants module per repo.
That rule read as paranoid the day I wrote it, but I adhered to it anyway, with the rename named in the comment as the potential driver. I spent a lot of time talking through the pitfalls and critical decision points of starting a company with different AI models before I ever did, and I had a pretty solid foundation of what I thought needed to be dynamic and fluid, and where the static could live.
The payout
Three mechanics were already in place by the time I needed them:
- The zone set is a Terraform variable and IAM record-write scoping derives from it. Adding the new domains was a tfvars change and an apply.
- The environment-to-domain registry is keyed so one environment can carry MULTIPLE active domains at once. Old brand and new brand served side by side for a week off that one keying decision, every DNS automation fanning out to both on every event, nothing able to drift between them because the fan-out was structural.
- Consumers ran dual-listen on event contracts: normalize the new brand prefix to the old canonical at the handler boundary, so every producer could flip on its own schedule.
Cutover day came down to registering zones, adding rows, verifying dual-serve, and flipping primaries, and retirement came down to deleting the old rows. The automation stopped touching the old zones because the data no longer named them, and not one line of code changed or got redeployed to make that happen.
What broke anyway
Renaming a GitHub Org moves every repo URL, which everybody expects, and it also moves every OIDC trust subject that embeds the org name, which is the part with teeth: CI roles in five AWS accounts trusted federated subjects carrying the old string. I had pre-staged most of the trust updates and still spent the afternoon chasing stragglers while the pipelines sat broken and watched me suffer. If you ever attempt this, enumerate every token.actions.githubusercontent.com trust condition in every account BEFORE the rename. All of them. Any condition you miss leaves that account’s pipelines locked out of their roles until you track it down by hand, after the rename, while everything else is demanding your attention too.
And the first post-rename account vend failed on one variable. Just One. The rename’s lockstep scope included the management-account org stack, and a broker role trust inside it still carried an old value. That stack gets applied rarely and reviewed rarely, which is exactly why it was the one that got missed, and the rule I took out of it is that a rename’s blast radius ALWAYS includes the org and bootstrap stacks. They get their own checklist line now, because a stack you only apply a few times a year never crosses your mind when you are listing out what a rename touches.
Footnote: This part didn’t HAVE to break, because I could have just left it and the infrastructure would have worked fine, but I am a bit OCD with these things. Before the name change I thought I was being witty with an AWS resource name prefix initialed after the original company name. That bit hard, because if I was going to change the name I wanted no remnants to remain, including those prefixes. So every service got updated, every resource got redeployed, every system got migrated in a single sweep, and there were definitely bumps along the way but I would do it all again for the peace of mind.
Final thoughts
Changing names hurt a lot, and it was weeks before I accepted the truth of it, it quite literally took the lawyer telling me he doesn’t advise it before I realized I had already been grieving. A strange thing to grieve for sure, but you invest yourself in the company you start, and you push all your hopes and dreams into it, aspirations and ambitions and that all gets associated with a single identity. You talk about it with family and friends, they know it by name and the name shapes the design at times. All to be told that the identity you have associated it with all this time is unavailable to you. Should I have done my due diligence? Yeah, of course, but I bought the domain over a year ago and there were no conflicts and nothing returned on search, because the other company didn’t go live until nine months ago, and I only started on this solo founder journey six months ago, and had little trademark know-how. I know better now, I created an arguably better name, the trademark is pending, the shape has changed, the look and feel are different, but it taught me a lot. To be more dynamic in decisions, to not tie my efforts to an identity, that change can be good.
Would the no-brand-strings-in-code rule have been worth it if the trademark conflict never came? Yes, and that caught me off guard. The same data-not-code posture is what later let the whole platform collapse its per-environment stacks into singletons, domains-as-rows generalizing into environments-as-rows without my having to argue for it a second time. I wrote that rule to survive a rename and it turned out to be holding up the architecture.
And because I can’t just leave the last line with “Hey I abolished all my environments and collapsed them into monoliths” that isn’t the case. What we did was take services that didn’t need to change after deployment, and didn’t need a staging environment because they don’t affect customers, and allow them to serve multiple environments in other areas. Our DNS Register microservice which EVERY account uses to register ACM certificates or DNS aliases, did not NEED a dev, test, stage, and prod environment. Same with our Dashboarding / Metrics microservice, etc. The restructure of the name was part of what built the realization that we had never deployed the entire company stack from the ground up, we didn’t KNOW the full mapping of interdependencies to go from complete catastrophic failure back to completely deployed, and that streamlining effort and chasing efficiency shaped how some of those systems were designed.