DeveloGogh

The brief

DeveloGogh was created to give a family of focused products a shared commercial and identity layer. The temptation with a suite is to make one giant application and call the problem solved. That creates a different problem: product data, limits, user accounts, and release cycles become coupled even when the products have different jobs.

The required boundary was clear. DeveloGogh should be the authority for organization identity, membership, trials, billing, and entitlements. ProtoGogh, QAGogh, and InspectGogh should remain independently deployable and keep their own product data. A person or workspace should be linked deliberately, never guessed from an email address.

One authority without one monolith

The launchpad is the visible expression of the architecture. It gives an organization a home for product launches, team membership, seat usage, plan state, and billing actions. The product cards communicate whether a linked workspace is ready, needs setup, or needs an explicit account link. That state is not decorative; it is the result of the central entitlement and mapping model.

DeveloGogh starts with a verified account and a 14-day trial. Stripe remains the billing record once a subscription exists, while the suite owns the organization-level entitlement that product services consume. Plans describe seats and product limits in one place. When access is past due or expired, linked workspaces can remain readable while writes pause. That is a more honest failure mode than making product data disappear or allowing a stale cache to grant access forever.

Linking is an action, not a side effect

The most important identity decision is what does not happen. An existing ProtoGogh, QAGogh, or InspectGogh account is not silently merged with a DeveloGogh account because the email strings match. If a product account already exists, the user completes an explicit linking flow while authenticated to both sides. The central mapping is created from the verified OAuth subject and product callback, not from an untrusted request-body identifier.

The integration uses authorization code flow with S256 PKCE. Callback handling validates the state, issuer, audience, token expiry, nonce, and stable subject before creating a mapping. Those checks make account linking legible: a person can see that a link is being created, and the receiving product can verify where the assertion came from before changing ownership or access state.

This preserves useful independence. A standalone product user can keep working in that product without a suite organization. A linked workspace can use suite-controlled limits and membership. Both cases remain representable because linking is stored as an explicit relationship rather than inferred as a global identity rewrite.

Event delivery with evidence

Central decisions still have to reach product systems. DeveloGogh signs the exact raw JSON body for central-to-product events using a timestamp, event ID, and body digest. It retains a delivery ledger, retries failures with bounded exponential backoff, and treats a successful product acknowledgement as a meaningful state transition. That gives operators something better than “the webhook probably fired”: there is a record of what was delivered, to whom, and whether the product accepted it.

Product-side caches fail closed. A missing, stale, or non-writable suite entitlement must not turn into accidental write access. This is especially important when the suite and products are independently deployed. The receiving product has to be able to protect its own data even when the central service is temporarily unavailable.

The product result

DeveloGogh makes a suite feel connected without pretending that three products are one screen. The launchpad provides a clear path from account creation to product setup. Membership and billing have one owner. Entitlements can be reasoned about centrally. Product data remains in the product that created it. Linking is explicit and reversible at the relationship boundary.

That is the useful kind of platform work: fewer duplicated decisions, clearer ownership, and enough independence that the suite can evolve without turning every product release into a coordinated rewrite.