In Q1 2026 the CNCF Platform Engineering Technical Community Group (TCG) started refreshing two foundation documents: the Platform as a Product white paper and the Platform Engineering Maturity Model. The community aims to publish drafts before KubeCon EU 2026 and to bring AI-tool safety into platform governance. A CNCF practice post on 29 May 2026 is blunt: modern delivery is no longer limited by application code, but by the platform that runs it. For a custom-delivery shop such as XYN Tech, that sentence is closer to the real pain than “hire two more backend engineers”—environment drift, secrets baked into pipelines, rollback by hallway agreement, and observability added only after an incident.
1. Split the three layers before asking “do we need Kubernetes?”
That CNCF write-up splits the platform into infrastructure, platform, and application layers and warns that folding them into one repository early makes later maintenance explode. Infrastructure owns networks, clusters, registries, and the secret store. The platform layer provides the GitOps controller, policy, service mesh, and observability. Only the application layer is the customer’s business services. The most common mistake in custom projects is keeping customer code, Jenkins scripts, and cluster parameters in one document, so every new environment means rewriting the whole repo.
1.1 Small teams should not copy a hyperscaler’s tool list
The same article admits that stacking overlapping tools too early is a typical CNCF-ecosystem trap. Istio, OpenTelemetry, and multi-cluster ApplicationSets can wait. For a six-month custom delivery, the honest minimum is a reproducible environment definition, a build pipeline with scan and sign, and Git as the single source of truth. Without those three, a “microservice rewrite” is just a monolith split into processes that copy each other’s config.
2. Treat the platform as a product, not a pile of ops scripts
CNCF frames platform engineering as “Platform as a Product”: the point is not buying another portal, but treating internal developers as customers. A 2026 revision focus is adding real scenarios so an organization can see its current level and change only one next thing. If a custom-software firm builds Jenkins, Dockerfiles, and test databases from scratch on every project, delivery time is eaten by a “repetition tax.” The first job of an internal developer platform (IDP) is a golden path for similar projects: create the repo, request an environment, run tests, preview, release. Developers fill in only the business deltas.
- Declarative infrastructure: environments can be rebuilt, instead of “only Wang can log into that box.”
- GitOps reconciliation: cluster state follows Git; a manual kubectl change in production can be pulled back.
-
Supply chain on by default: dependency scans, image signing, and a ban on the
latesttag before anything reaches the cluster. - Observability as a platform capability: metrics, logs, and alerts come with the golden path, not as a post-go-live retrofit.
3. Move supply-chain checks to “before it can deploy”
The CNCF IDP practice splits build, security validation, and infrastructure change into separate pipelines. The app pipeline compiles, unit-tests, runs SAST, scans dependencies with Trivy, and signs with Cosign before the registry. A security pipeline re-checks signatures, scans images, and reviews manifests with KubeSec. Only then may the GitOps controller sync. In their lab and staging they saw deploy success rise from about 70% with manual steps to about 95%, infrastructure prep fall from hours to under 15 minutes, and about 80% of findings caught before production. Those numbers are lab observations, not customer promises—but the direction is clear: move verification from “someone staring at a screen” to “the pipeline refuses.”
| Layer | Platform capability | What it maps to in custom work | Do not start here |
|---|---|---|---|
| Infrastructure | Network, cluster, registry, secrets | Customer test / staging / production bases | Hand-editing security groups without writing them back |
| Platform | GitOps, policy, observability | One release, one rollback, one alert path | A private Jenkins philosophy per project |
| Application | Independently releasable services | Orders, inventory, approvals | Baking secrets into the same image as business code |
| Governance | Signing, admission, audit | Contract security clauses a machine can check | A verbal “we will scan before go-live” |
4. A landing order for custom-delivery teams
The maturity model stresses an executable next step, not buying a portal in one shot. XYN Tech cuts the thinnest golden path by project type—for example Java + MySQL + object storage first, then front end and messaging. Admission policies such as Kyverno should first block latest images and plaintext secrets. Do not flip Istio mTLS to Strict cluster-wide: that write-up notes early Strict breaks services without sidecars. Start Permissive, then tighten per namespace.
- Freeze one environment module (network, compute, secrets) and separate dev / staging / prod with variable files.
- Turn build output into a verifiable artifact: version, scan report, and signature must exist before staging.
- Make Git the release entrance; rollback means reverting a commit, not overwriting files on a box.
- Only then build a self-service portal. Without the first three steps, a portal is chaos with buttons.
Platform engineering is not there to make a custom project “look cloud-native.” It exists so the second delivery of the same kind of system is not slower than the first. If you are scoring several enterprise systems in parallel, count the hours the team spends waiting for environments, reconciling config, and guessing who changed what—then pick which line gets the golden path. That is easier to accept at the next milestone than a grand middle-platform blueprint.