Most internal developer platforms fail not because the architecture is wrong, but because product teams don’t use them. The platform that ranks highest on engineering elegance often ranks lowest on internal NPS. The platform that’s actually adopted has fewer features, simpler abstractions, and a team that treats product engineers as customers.
Ænix builds internal developer platforms (IDPs) that get adopted. Not Backstage as wallpaper over chaos; an opinionated platform with golden paths, multi-tenant foundations, and operational handoff your platform team can sustain.
Pairs with: Developer self-service(/products/private-cloud-platform/) — Internal Developer Platform layer (GitLab automation, Argo CD workflows, APIs, golden paths, productivity dashboards) on top of the Cozystack cloud foundation. Free Platform Engineering Maturity Assessment →.
Who needs an internal developer platform
Internal developer platform investment fits when:
- 3+ product teams with overlapping infrastructure and provisioning needs
- Time-to-environment of weeks for what should take hours
- Multiple inconsistent infrastructure patterns evolved per team
- Existing platform / DevOps function maxed on tickets — no capacity for self-service work
- Specific pressure (regulator, cost, sovereignty, scaling) makes structured platform investment timely
If your situation matches three of these, structured IDP work returns adoption + velocity within months. If you have one product team and a small infrastructure surface, simpler shared-tooling practices deliver better cost/value.
What an Ænix IDP engagement produces
1. Opinionated golden paths 5-10 self-service paths covering the most common product-team needs: environment provisioning, application deployment, observability onboarding, secrets, identity, network connectivity. Documented, supported, audited.
2. Multi-tenant Kubernetes foundation Built on KubeVirt + Cilium + LINSTOR (Cozystack pattern) or extension of your existing Kubernetes platform. Tenant CRD, per-tenant quotas, RBAC, audit. Suitable for enterprise multi-BU or service-provider multi-customer use.
3. Developer-portal layer where useful Backstage (CNCF Incubating) when the catalog discipline is mature; alternatives (Port, Cortex, custom) when better fit. Portal is the visible part; the platform sits underneath.
4. Operational model and runbooks Documented platform-team responsibilities, on-call patterns, capacity planning. Knowledge transfer throughout. Your team operates the platform after we leave.
The output is measured in adoption metrics — time-to-environment, golden-path adoption rate, internal NPS — not feature count.
Where IDP programs commonly fail
Backstage as the platform Buying Backstage without an underlying opinionated platform produces a beautiful catalog over the same operational mess. Self-service paths still take weeks; the catalog is just a richer waiting room.
Building for engineers, not for product teams Platform team’s customers are product engineers. Architecture optimized for engineering elegance often produces a platform nobody wants to use the way it was designed.
Vendor-led “complete IDP” lock-in Several vendors sell pre-packaged IDPs. They work for narrow customer profiles but rebuild lock-in with a different vendor. The vendor’s roadmap becomes your roadmap.
Platform team absorbed by tickets Without explicit headcount and protected golden-path work time, the platform team becomes ticket support. Self-service work stalls.
How Ænix engages
The IDP engagement runs in three phases:
- Phase 1: Platform Readiness Assessment (14-28 days) — current-state platform maturity, target IDP architecture, golden-path priorities, RACI for platform team. See Platform Readiness Assessment.
- Phase 2: Build engagement (3-9 months) — Ænix engineers integrated with your platform team, building the foundation, golden paths, and runbooks. Knowledge transfer is a first-class deliverable, not an afterthought.
- Phase 3 (optional): Managed operation — for organizations that need the IDP but cannot build internal platform-team capacity.
Engagements typically start with Phase 1; Phase 2 sequencing emerges from assessment.
Why Ænix specifically
- Backstage is a tool, not a destination. We don’t sell it, so we can tell you when a catalog is the wrong first move and a documented golden path is the right one.
- Multi-tenancy is the part that is hard, and it is what we run. Cozystack is in production with service providers and regulated enterprises operating multi-tenant clouds; the tenancy model we propose is one we operate.
Engagement structure
| When | What | Output |
|---|---|---|
| Day 0 | 30-min discovery call (free) | Confirm fit, identify scope and IDP stage |
| Phase 1: Assessment (14-28 days) | Platform Readiness Assessment | Target IDP architecture, golden-path priorities, RACI |
| Phase 2: Build (3-9 months) | Foundation + golden paths + runbooks + knowledge transfer | Production IDP, operational by your team |
| Phase 3: Operate (optional, ongoing) | Managed-services or fully in-house | Sustained IDP |
For methodology see Platform Readiness Assessment.
IDPs we’ve built
We’ve built internal developer platforms for service providers running multi-tenant clouds, regulated enterprises with strong sovereignty requirements, AI/GPU operators with multi-team data-science access, and telecom operators consolidating multiple legacy environments.
Pricing
The assessment is fixed-price, quoted before it starts, and delivers a written target IDP architecture and a Phase 2 roadmap. The build is time-and-materials or fixed-scope. If Phase 2 follows, the assessment cost is credited against it, subject to scope.
Start with a 30-minute discovery call
Or read more:
- IDP examples without Backstage lock-in — practical patterns
- Platform engineering services — broader scope
- Platform Readiness Assessment — assessment methodology
- Cozystack — the foundation we typically build on
Ænix is the platform engineering team behind Cozystack — a CNCF Project, Kubernetes Certified Distribution, OpenSSF Best Practices.




