The 80/20 Approach to Platform Engineering

1The 80/20 approach to platform engineering

Most platform products begin with the same ambition: support every cloud, every runtime, every workflow, every team, and every operating model.

That breadth is useful in the right environment. It is also expensive in another sense. It creates more decisions, more configuration, more integration work, and more platform machinery to operate before developers feel any improvement.

Vertro takes a narrower approach.

It focuses on the recurring problem that slows down most new Applications on Google Cloud and GKE: getting from a developer request to a secure, production-ready foundation without weeks of tickets, handoffs, and repeated engineering work.

The goal is not to build the biggest platform. The goal is to remove the most friction with the least unnecessary weight.

2The problem is rarely a lack of tools

Most teams already have the building blocks. They have Terraform. They have GitHub. They have GKE. They have CI/CD. They may already have policies, security requirements, and naming standards.

Yet a new Application still creates the same chain of work. A project must be created. IAM must be configured. A namespace must be prepared. Runtime identity must be established. Repositories and workflows must be created. Delivery must be connected to GKE. Security and governance must be checked.

None of this is unusual, but organizations often handle it as if every request is new. The work moves from one person to another. One engineer copies Terraform. Another adjusts a pipeline. Someone reviews IAM. Someone else creates the namespace. The developer waits while the request travels between teams.

Vertro turns that repeated work into one supported path. It does not try to replace every system in the engineering organization — it connects the systems already responsible for infrastructure, identity, delivery, and policy, and gives each one a clear role.

The result is not a new abstraction over everything. It is a practical way to make the existing platform behave consistently.

3Why focus matters

Broad platforms give teams flexibility. They can support multiple clouds, many runtime types, different developer experiences, custom resource models, and complex orchestration patterns.

That flexibility can be powerful. It also transfers a large design burden to the customer. The platform team still has to decide how the product should represent Applications, Environments, infrastructure, identity, delivery, policy, and ownership. It must build or configure the integrations. It must maintain the platform model as the organization changes.

Vertro begins with fewer open questions. It is deliberately opinionated about the Google Cloud and GKE path.

That means less time designing the platform before using it. Fewer competing ways to perform the same task. Fewer moving parts to explain. Fewer layers between the request and the systems that apply the change.

This does not remove platform ownership from the customer. The customer still decides the important things: network architecture, IAM boundaries, approved infrastructure patterns, security requirements, Environment structure, and governance rules.

4A platform should become useful quickly

A custom platform initiative often starts with months of design. The team debates portal structure, resource models, plugins, workflows, ownership, templates, and integration boundaries. By the time the foundation is ready, the original developer pain may still be unresolved.

Vertro starts from patterns that already exist. The repository structure, identity approach, Git workflow, infrastructure path, GKE model, and delivery pattern do not begin from a blank page. They are adapted to the customer's environment rather than invented from scratch.

That is why Vertro can target a focused implementation in weeks. The speed does not come from skipping architecture — it comes from avoiding the repeated design of common platform patterns.

The implementation still has to fit the customer's Google Cloud organization, GitHub model, networking, security controls, and delivery requirements. But the starting point is already practical and tested as a coherent model.

That changes the conversation. Instead of asking, "What kind of platform should we build?" the team can ask, "Which parts of this working model need to change for our environment?"

5Lightweight means less operational drag

Vertro is lightweight by design. That does not mean incomplete. It means the platform avoids unnecessary layers, overlapping responsibilities, and broad abstractions that add operational drag without solving the immediate problem.

The core path remains visible. A developer request becomes generated changes. Those changes appear in Git. The responsible systems apply them. The customer can inspect what was created, understand which tool owns it, and see how it should be changed later.

There is no need to hide the platform behind a large proprietary model. The implementation remains grounded in standard tools the team can operate directly.

That matters over time. Platforms become difficult to manage when responsibility becomes unclear — one system creates infrastructure, another modifies it, a workflow overrides it, and a manual change quietly becomes permanent.

Vertro avoids that ambiguity by keeping one authoritative management path for each resource class.

The platform stays understandable because its responsibilities stay visible.

6Founder-led delivery

Platform implementation is not a simple software installation. It involves architecture decisions, trade-offs, and judgment. Identity boundaries need to make sense. Networking needs to fit the organization. Repository and Environment structures need to support how teams actually work. Security controls need to be strong without creating unnecessary friction.

In a large vendor engagement, those decisions often pass through several layers. The customer speaks with sales, then a solution architect, then an implementation team, then support. Context is transferred. Questions wait. Trade-offs are revisited.

Vertro is founder-led. The person discussing the architecture is directly involved in shaping and implementing it. That reduces handoffs and makes decisions faster.

It also keeps the engagement focused. The goal is not to expand the implementation until it becomes a large transformation programme. The goal is to identify the smallest platform foundation that solves the real problem and gives the customer a stable base to build on.

That direct involvement is part of the product.

7Ownership changes the long-term equation

Vertro is implemented inside the customer's own Google Cloud and GitHub environment. The customer keeps the repositories, Terraform state, GKE clusters, workflows, Config Sync configuration, Argo CD configuration, Helm packages, policies, and generated Application configuration.

This is not the same as saying there are no dependencies. Every platform introduces conventions and operating assumptions. The difference is that the core foundation remains visible and customer-owned.

If the organization later changes direction, the underlying platform foundation remains. Vertro-specific orchestration would require a transition plan, but the customer is not left without the infrastructure, workflows, and configuration already created.

That reduces long-term operational and commercial dependency.

8A different commercial model

Many platform products are sold as recurring software subscriptions. That makes sense when the customer is buying a large, continuously operated product with a broad feature set and an ongoing vendor control plane.

Vertro follows a different model because it is a different kind of offering. The customer is paying for a focused implementation that establishes a working platform foundation inside its own environment.

There are no per-seat fees and no usage-based platform charges. The value is in the implementation, the operating model, the automation, and the customer-owned result.

This makes Vertro a better fit for teams that need real platform capability but do not want to commit to a large recurring software contract before proving the value of the platform itself.

The objective is not to be the cheapest option. The objective is to make the investment proportionate to the problem being solved.

9How Vertro is different

Vertro is not the right choice for every organization.

A company that needs one enterprise platform spanning AWS, Azure, Google Cloud, on-premises infrastructure, many runtime models, and multiple business units may need a broader product. A company that primarily wants a large software catalog across all internal systems may need a different tool.

Vertro is built for teams standardizing Google Cloud and GKE.

10Why Vertro exists

Vertro was created after seeing the same pattern repeatedly across Google Cloud environments. The organizations were different. The tools were different. The maturity levels were different.

The friction was familiar.

Developers waited for infrastructure and access. Cloud engineers repeated project and IAM work. DevOps teams maintained inconsistent delivery paths. Security teams reviewed the same concerns Application by Application. Platform engineers spent too much time processing requests and not enough time improving the platform.

The organizations did not need more tools. They needed a working path through the tools they already had.

Vertro packages that path into a focused implementation. It does not try to solve every platform engineering problem. It solves the recurring problem that prevents new Applications from moving quickly and consistently.

That is the 80/20 approach.

11Frequently asked questions