The platform engineering movement is accelerating — and most teams are building it wrong.
They're adopting Backstage, standing up Kubernetes operators, hiring dedicated portal teams, and spending 6-12 months before delivering any real value to developers. Meanwhile, the actual developer platform — the thing engineers use every single day — is sitting right in front of them.
It's GitHub.
I built an enterprise-scale internal developer platform at a Fortune 500 energy company. Thousands of developers, hundreds of repos, strict compliance requirements. We didn't need a separate portal because GitHub already IS the platform — the service catalog, the self-service automation, the golden paths, the governance layer. All native primitives, composed together.
Here's the overview of how that architecture works — and the 7 open-source repos that make it real.
Want the complete implementation? This article covers the architecture and approach. The full step-by-step guide — with IssueOps workflows, Copilot extension code, and hookflow governance configs — lives in Issue 008 of the htek.dev newsletter. Subscribe to get it →
The Platform Engineering Movement Is Real — But the Tooling Is Wrong
Platform engineering isn't a trend. It's a structural response to a measurable problem: developer teams spend 30% of their time on operational tasks instead of shipping features. The CNCF Platform Engineering Maturity Model formalized this, and Team Topologies gave us the vocabulary — platform teams exist to reduce cognitive load for stream-aligned teams.
But the industry made a wrong turn. Everyone assumed platform engineering meant Backstage.
Backstage is powerful — and it's also a React application requiring a PostgreSQL database, a dedicated team to maintain, a plugin ecosystem with varying quality, and months of customization. The 2025 Backstage Adopter Survey showed most teams take 6-12 months to reach "useful." Many never get there.
If your developers already live in GitHub — PRs, issues, Actions, Codespaces — why send them to a separate portal?
The 4 Capabilities Every IDP Needs
Every internal developer platform, regardless of implementation, needs four core capabilities:
1. Self-Service Provisioning
Developers need to spin up environments, repos, and infrastructure without filing tickets. On GitHub, this means IssueOps — open an issue with a structured template, and GitHub Actions provisions everything automatically.
2. Golden-Path Templates
Opinionated, well-lit routes through your stack. Developers can deviate — but the default path is fast, correct, and maintained. On GitHub? These are starter repos with embedded AI context via copilot-instructions.md.
3. Governance & Guardrails
Policy enforcement that doesn't require developers to remember rules. On GitHub, this is Copilot hooks and extensions — guardrails that intercept dangerous operations before they happen, not after.
4. Unified Developer Experience
One place where developers see their services, their environments, their compliance status. On GitHub, you already have the repo as the unit of ownership — what's missing is the composition layer, which GitHub Copilot extensions now provide.
Why GitHub-Native Wins Over Backstage
The fundamental advantage: zero adoption friction.
Your developers are already authenticated to GitHub. They already know how to open issues, review PRs, and trigger Actions. A GitHub-native IDP doesn't require new logins, new UIs, new mental models, or new SSO integrations.
Here's the architectural comparison:
| Capability | Backstage Approach | GitHub-Native Approach |
|---|---|---|
| Service catalog | Custom plugins + PostgreSQL | Repository topics + CODEOWNERS + org-level metadata |
| Self-service | Software templates + scaffolder | IssueOps + reusable Actions |
| Golden paths | Template catalog | Starter repos + copilot-instructions |
| Governance | TechDocs + manual reviews | Copilot hooks + required workflows |
| Developer UI | Custom React portal | GitHub UI + Copilot chat extensions |
The GitHub-native approach isn't "less capable." It's differently capable — and it ships in weeks, not months.
The 7 Starter Repos
I've open-sourced the building blocks as 7 starter repositories. Each handles one piece of the IDP puzzle:
- copilot-instructions-starter — Golden-path context engineering templates that shape how AI agents interact with your codebase
- copilot-hooks-starter — Hook configurations and safety guardrails for controlling what AI agents can and cannot do
- copilot-agent-starter — Multi-agent delegation patterns and orchestration templates for PR review, deployment, and triage
- issueops-starter — Self-service provisioning workflows triggered by structured issue templates
- github-governance-starter — Organization-wide policy enforcement via required workflows, rulesets, and compliance checks
- platform-catalog-starter — Service catalog metadata conventions using repository topics, custom properties, and CODEOWNERS
- golden-path-app-starter — A complete application template wired with all of the above — the "new project" button for your platform
Each repo is standalone but designed to compose. The platform team maintains the starters; stream-aligned teams consume them through gh repo create --template.
Newsletter subscribers get the full implementation details — complete IssueOps workflow YAML, Copilot extension source code, hookflow governance configs, and the composition patterns that wire all 7 repos together. Subscribe to Issue 008 →
How This Connects to Context Engineering
If you've read my piece on context engineering, you already understand the core insight: the quality of AI output is determined by the context you provide, not the prompts you write.
Golden-path starter repos are context engineering at the organizational level. Every new repo created from a starter inherits:
- Architecture decisions (via
copilot-instructions.md) - Safety guardrails (via hook configurations)
- Governance rules (via required workflows)
- Agent behaviors (via agent definitions)
This is what I call the three layers your AI agent is missing — scaled to the platform level. And it ties directly into the governance stack I wrote about recently.
The Blueprint: Part 4 — Platform Engineering
I'm releasing a new Part 4: Platform Engineering chapter in The Agentic Development Blueprint. It covers the full architecture — from IssueOps provisioning flows to Copilot extension development to hookflow governance patterns — with production-ready code and configuration you can deploy this week.
If you're already running the blueprint patterns from Parts 1-3 (agent harnesses, multi-agent orchestration, context engineering), Part 4 shows how to scale those patterns across your entire organization as a platform team.
The Bottom Line
You don't need Backstage. You don't need a 6-month implementation timeline. You don't need a dedicated React portal team.
You need GitHub — which you already have — composed with IssueOps, golden-path starters, Copilot extensions, and hook-based governance. The platform is already there. You just need to wire it together.
This was the overview. The newsletter issue has the full step-by-step implementation — complete IssueOps workflows, Copilot extension code, all 7 repos explained in depth, and the composition patterns that make them work together.
→ Subscribe to the htek.dev newsletter to get Issue 008
Related reading:
