How would a self-service CI/CD platform handle a team that's on a fundamentally different tech stack the golden path doesn't cover well?

Design the platform's core (orchestration, secrets, deployment tracking, observability integration) to be stack-agnostic, with the golden path's stack-specific tooling (build templates, test runners, language-specific optimizations) as a pluggable layer on top — a team on a different stack can then build their own stack-specific plugin/template that still integrates with the platform's stack-agnostic core, getting the shared benefits (centralized secrets, deployment tracking, observability) without needing the platform team to have built first-class support for their specific stack.

The key architectural move is separating what the platform actually provides value through (a stack-agnostic core) from what makes the golden path convenient for the dominant stack (stack-specific tooling built on top of that core) — a distinction the design below makes explicit.

• The platform must not force a genuinely bad technical fit onto a team whose stack doesn't match the golden path.
• The team on a different stack shouldn't be left entirely outside the platform's shared benefits (secrets management, deployment visibility, observability).
• Supporting this team shouldn't require the platform team to build and maintain deep expertise in every possible tech stack that might ever show up.

Separate the stack-agnostic core from stack-specific tooling explicitly: the platform's actual core value — centralized secrets management, deployment tracking/audit trail, observability integration, environment provisioning — doesn't inherently depend on any specific tech stack; it's about what gets deployed and how it's tracked, not the build mechanics of a specific language ecosystem. Structuring the platform so this core is genuinely stack-agnostic (accepting, say, a built artifact and a deployment manifest in a standard format, regardless of what produced them) means a team on a different stack can still plug into this core value without needing the golden path's specific build tooling to fit their stack.

Golden path as a pluggable convenience layer, not the platform's only interface: the golden path's stack-specific tooling (optimized build templates, test runner integration, language-specific caching) is genuinely valuable for the dominant stack, but framing it as one plugin/template built on top of the stack-agnostic core — rather than the only way to interact with the platform at all — leaves room for a different team to build their own plugin for their own stack, following the same core integration contract (produce an artifact + manifest in the expected format) without needing the platform team to have anticipated their specific stack.

Let the outlier team own their stack-specific tooling, with platform team support on the integration contract: rather than the platform team building deep expertise in every possible stack, the team with the unusual stack builds and maintains their own build/test tooling, with the platform team's involvement scoped to helping them correctly implement the core integration contract — this scales much better than expecting one central team to be expert in every stack the organization might ever use.

Explicit process for eventually promoting a working outlier integration into a supported path: if the "outlier" stack turns out to be used by more than just one team over time, what started as one team's custom plugin can be promoted into a second, officially-supported golden path — turning organic, bottom-up demand into a first-class platform offering, rather than either ignoring repeated demand or over-investing in a stack that turns out to be genuinely rare.

A stack-agnostic core with pluggable stack-specific layers is more architecturally complex to build initially than a platform tightly coupled to one specific golden-path stack — worth the investment specifically because it avoids the alternative failure modes (forcing a bad fit, or maintaining a completely separate unsupported system for outlier teams). The outlier team bears more of their own tooling burden than a golden-path team does, which is a real cost to them, but is the appropriate trade-off for a genuinely non-standard stack rather than the platform team trying to be expert in everything.

• Separating the platform's stack-agnostic core (secrets, deployment tracking, observability) from stack-specific tooling (build templates) lets an outlier team plug into shared value without needing first-class golden-path support for their specific stack.
• The golden path should be one pluggable convenience layer on the stack-agnostic core, not the platform's only interface.
• The outlier team owns their own stack-specific tooling, with the platform team's involvement scoped to the shared integration contract — this scales better than one team trying to be expert in every stack.
• A process for promoting a proven outlier integration into a second official golden path turns organic demand into a first-class offering when it's genuinely warranted.

• Team Topologies: Platform Teams
• platformengineering.org: What is an Internal Developer Platform?