The auth service learned which product it was acting for

The auth service started out treating every product the same. One behavior, one set of assumptions, all products. With a single product, nothing pushed back on that.

The second product pushed back immediately — a separate app, its own brand, its own users.

The symptom was a broken welcome. An admin creates a user for the new app; the setup email arrives wearing the first product's name, and the link leads back to the first product. Every step "works," yet the experience is wrong. The cause was not the email copy or the redirect. It was that the service had no concept of which product an action belonged to.

What changed

The fix was not cosmetic and it was not in the templates. It was upstream: every user action had to carry the product it belonged to, from the moment it was created all the way to the email and the page the user lands on. Once the action knew its product, the right brand, the right destination and the right tone followed without special-casing anything.

In before/after terms:

The change was small where it was made. The downstream effects were not.

Why this was the right moment

The second product was the pressure that forced it. Without a real second consumer, the single assumption felt fine. With one, the mismatch was immediate and visible.

This is a pattern I keep seeing: shared infrastructure stays happily generic until a second real consumer appears. The second consumer does not create the problem — it reveals the assumption that was always there. Here the assumption was every action belongs to the same product. Replacing it with every action carries its product was the right architectural step, not because it was elegant, but because it was the only way to keep two products coherent.

Part of my platform notes. Follow the blog or contact me.