TL;DR: Build internal platforms that enable teams to ship faster with standardized infrastructure.
Scale your engineering organization without the operational drag. In 2026, the term “Internal Developer Platform” (IDP) is often buried in hype. But at its core, an IDP is about one thing: Developer Velocity.
I help North American engineering leaders move away from ‘Ticket-Ops’ and toward a self-service reality. I don’t build ‘heavy’ portals that developers ignore; I build foundational paved roads that turn developer intent into production infrastructure automatically.
IDPs are often framed as a developer experience problem. That’s only half true.
What teams are actually struggling with is:
Slow project creation and environment setup
Inconsistent IAM and security baselines
Manual service account and identity wiring
CI/CD pipelines that don’t scale securely
Terraform repos that start from scratch every time
An IDP should reduce cognitive load and operational risk, not just add a UI.
Most IDPs fail because they prioritize the “Dashboard” (UI) over the “Plumbing” (Foundations). If your underlying IAM, Networking, and CI/CD identity aren’t solved, a pretty portal is just a wrapper for a broken process.
In my experience, a portal is useless if the underlying plumbing is broken. I’ve seen teams spend six months building a UI only to realize they still haven’t solved the fundamental issues of IAM and Networking isolation.
In my experience, most IDP initiatives fail for predictable reasons:
They start with a portal instead of foundations
They expose too many choices instead of opinionated defaults
They wrap Terraform without solving identity, security, or ownership
They require platform teams to act as gatekeepers again
The result is a platform that looks impressive but is rarely used.
The IDP I recently built follows a simple principle:
If developers can safely self-serve the hard parts without a UI, you’re already 80% of the way there.
Instead of a portal, the platform is driven by a single declarative YAML file that represents developer intent.
Declarative Environment Vending: Projects are provisioned via YAML, not clicks. This ensures 100% auditability and consistency.
Declarative project intent (YAML): Developers define needs in a simple file—no GCP console access required.
Automated GCP project creation: Automatically attaches billing, applies folder policies, and sets up standard networking.
Zero-Trust CI/CD Identity: We automate Workload Identity Federation (WIF) so developers never touch a service account key again.
Opinionated Security Guardrails: Policy-as-Code (Terraform/Sentinel) ensures that every self-serviced project is compliant by default.
Scaffolded Developer Experience: We provide “Golden Path” templates that include monitoring, logging, and networking from day one.
Infrastructure as Code: Terraform & Google Cloud Config Connector.
Identity: Workload Identity Federation (WIF) & Access Context Manager.
Security: Google Cloud Armor & VPC Service Controls.
CI/CD: Github Actions, Google Cloud Build, and Artifact Registry.
Governance: Cloud Asset Inventory and Security Command Center.
This approach works because it aligns with how teams actually operate:
YAML is reviewable (PRs, approvals, audit)
Terraform remains visible, not hidden
Security is embedded, not bolted on
Platform teams define the paved road, not every possible road
Most importantly, it scales with maturity. A UI can always be added later—foundations are much harder to retrofit.
Platform engineering is not about building more tools.
It’s about removing unnecessary decisions from developers while preserving flexibility where it matters.
A good platform:
Limits choices intentionally
Makes the secure path the easiest path
Encodes organizational knowledge into defaults
Evolves incrementally, not all at once
This IDP does exactly that.
At Buoyant Cloud, this is the approach we consistently take with platform engineering engagements:
Assess platform and org maturity
Design minimal but scalable platform foundations
Implement environment vending, identity, and guardrails
Enable teams before introducing portals or UI layers
The goal is not “an IDP”, but faster, safer delivery with less operational drag.
Is Your Engineering Team Stuck in “Ticket-Ops”? Stop waiting for infrastructure. Work with our Toronto-based Platform Engineering consultants to build a GCP Developer Experience Roadmap. We’ll help you eliminate friction and get back to shipping code.
Not necessarily. I am a firm believer in “Foundations First.” A portal like Backstage is just a wrapper. If your Terraform modules are standardized and your Workload Identity Federation is automated, your developers can self-serve via Git (YAML) today. You can add the “pretty” UI later.
Giving developers raw Console access is a recipe for security drift and “Cloud Spaghetti.” My approach uses Declarative Environment Vending. Developers state their intent (e.g., “I need a GKE cluster with a Redis instance”) in a YAML file, and my platform ensures it’s provisioned according to your organization’s security policies.
No. If you have more than two engineering teams, you are already wasting time on repetitive “plumbing” tasks. I build “Minimal Viable Platforms” for startups that provide 80% of the benefit with 20% of the complexity.
