Every enterprise team I talk to is drowning in the same problem: toolchain sprawl. Backstage instances nobody maintains. ServiceNow tickets that take 3 days to provision a repo. Confluence pages with onboarding steps from 2022. Developers spending 40% of their time fighting infrastructure instead of shipping product.

Platform engineering promises to fix this — and the industry agrees. Gartner predicts that by 2026, 80% of software engineering organizations will establish platform teams. But here's what most teams get wrong: they think they need to build another tool.

They don't. GitHub already is the platform.

Want the complete implementation? This article covers the architecture overview. Newsletter subscribers get the real configs, full code, and step-by-step implementation details. Subscribe to the htek.dev newsletter →

The Problem with "Build Your Own IDP"

I've seen it play out the same way at every Fortune 500 company I've worked with. A platform team spins up a Backstage instance, spends 6 months building plugins, and ends up with a portal that developers still don't want to use — because it's another tab. Another login. Another thing to maintain.

Meanwhile, every developer on the team already lives in GitHub 8 hours a day.

The insight that changed everything for me: the best platform is invisible. It meets developers where they already are — in their IDE, in their pull requests, in their issues. You don't need a separate portal. You need GitHub, used correctly.

The Golden Path Pattern

A golden path isn't a locked-down template. It's an opinionated default that accelerates developers without restricting them. Think of it like Rails conventions — you can deviate, but the default path is so good that most people don't need to.

In the GitHub ecosystem, golden paths are starter repos + Copilot context:

• copilot-instructions-starter — Drop-in .github/copilot-instructions.md templates that give Copilot the context to understand your org's conventions from day one.
• copilot-agent-starter — Scaffold custom Copilot CLI agents with proper extension architecture, hooks, and skill files.
• copilot-life-os-starters — Full starter kits for building agentic systems on top of Copilot CLI.

When a new developer joins the team and creates a repo from your golden-path template, they inherit the right CI/CD pipelines, the right Copilot context, the right linting rules, and the right security policies. Onboarding drops from days to minutes.

IssueOps: Eliminate the Ticketing Layer

Why send developers to ServiceNow when they can just open a GitHub Issue?

IssueOps turns GitHub Issues into the interface for platform operations. Need a new environment? Open an issue with a specific label. Need a database provisioned? Issue template with the right inputs. GitHub Actions picks it up, runs the automation, and comments back with the result.

The gh-aw-overview repo demonstrates this pattern — using GitHub's native primitives (Issues, Actions, labels, comments) as the control plane for platform operations. Developers never leave GitHub. No context switching. No ticket queue.

Hookflows: Governance Without Friction

The hardest part of platform engineering isn't building the golden path — it's keeping people on it without becoming a bottleneck.

This is where hookflows change the game. Hookflows intercept actions at the agent layer — validating commits, enforcing branch naming, checking policy compliance — before they hit the repo. They're governance guardrails that run automatically.

Combined with copilot-hooks-starter, you get a pre-built framework for intercepting and validating agent operations. The copilot-ci-pipeline repo extends this into CI — giving you a full feedback loop from commit to deployment.

I wrote more about this pattern in my article on governing AI agents in git — the principles apply equally to human and AI-driven workflows.

Newsletter subscribers get the real configs. The full hookflow definitions, the IssueOps action templates, and the architecture diagrams that connect all 7 repos into a cohesive platform. Get the implementation details →

The 7-Repo Stack

Here's the full stack, all open source and production-tested:

These aren't demos. I built and validated this stack while running a DevOps enablement platform at a Fortune 500 energy company — supporting hundreds of repos and dozens of development teams. The patterns scale.

Why GitHub IS the Platform

The realization that unlocked all of this: you don't need a separate platform layer. GitHub already has:

• Identity & access (Teams, CODEOWNERS, branch protection)
• Service catalog (repo topics, README conventions, copilot-instructions.md)
• Self-service provisioning (IssueOps + Actions)
• Compliance & governance (hookflows, required checks, audit logs)
• Developer AI (GitHub Copilot with full repo context)
• Deployment (Actions + environments + OIDC)

Every piece of Backstage functionality has a native GitHub equivalent — and developers already know how to use it. Your platform team's job isn't to build a portal. It's to configure GitHub as a platform and encode golden paths that make the right thing the easy thing.

Go Deeper

If you're building (or rebuilding) an internal developer platform, I wrote a full implementation guide as part of The Agentic Development Blueprint — including architecture diagrams, configuration files, and the decision framework for what goes in golden paths versus what stays flexible.

For related patterns, check out my guide to Copilot CLI extensions and how hookflows enforce governed git for AI agents.

---

This was the architecture overview. The newsletter issue has the step-by-step implementation — exact configs, IssueOps templates, hookflow definitions, and the full wiring diagram connecting all 7 repos into one cohesive IDP.

Subscribe to the htek.dev newsletter →