December 21, 2025·3 min read

I have been thinking about how to build Self-service developer platforms, and deal with trade-offs: how much infrastructure complexity to expose, how to serve different user needs, and how to balance flexibility with standardization.

Looking at various implementations—from open-source tools like Backstage¹ to commercial platforms like Heroku² and Vercel³—some recurring patterns emerge.

The Three-Tier Abstraction Model

Many platforms structure their interfaces around three levels of abstraction, each serving different use cases.

Tier 1: Minimal Input Templates

Backstage's software templates¹ demonstrate this approach—forms with minimal required fields:

Service Type: Web Service
Name: customer-api
Team: payments

[Create]

Behind this simplicity, the platform makes decisions about:

• Repository structure
• CI/CD configuration
• Deployment target
• Monitoring setup

Tier 2: Configurable Options

The same tools often support optional advanced fields:

Service: customer-api
Team: payments

▼ Advanced Options
  Environment: Production
  Resources: Medium (2 CPU, 4GB)
  Database: PostgreSQL - Standard

[Create]

Progressive disclosure—showing complexity only when requested—appears across many platform UIs.

Tier 3: Full Infrastructure Templates

At the detailed end, templates expose networking, scaling, cluster configuration, and other infrastructure parameters.

These tend to be used less frequently, primarily by platform teams or for specialized workloads.

Shared Development Clusters

AWS Proton's documentation⁴ discusses environment strategies. A common pattern that emerges:

Shared development cluster:

• Namespace-based isolation
• Resource quotas per team
• Lower operational overhead
• Automatic cleanup of inactive namespaces

Dedicated clusters:

• Reserved for production
• Or teams with specific isolation requirements

The trade-off: shared environments reduce costs and complexity, but require clear resource boundaries.

Progressive Disclosure

GitHub Codespaces⁵ provides a clear example—default simplicity with optional depth:

Repository: myapp
Branch: main
[Create]

▼ Advanced options
  Machine type: 2-core, 8GB
  Region: US West
  Timeout: 30 minutes

Most users never expand the advanced section. Those who need it can find it.

Environment Lifecycles

Heroku² and Vercel³ both automate environment progression:

• Pull requests create preview environments
• Main branch deploys to staging
• Production requires manual promotion

The platform determines where code runs based on git workflow, removing environment selection as a decision point.

Cost Visibility

Some platforms surface cost estimates before resource creation:

Estimated monthly cost:
  Compute: $150
  Database: $75
  Monitoring: $31
  Total: $256/month

[ ] Budget approved
[Create]

Whether this changes behavior is unclear, but it makes cost visible at decision time rather than after the fact.

Persona-Based Templates

Different templates for different needs:

Quick start:

• 3 input fields
• All defaults
• 5 minutes to deployment

Configurable:

• 8-10 options
• Recommended defaults shown
• 15 minutes to deployment

Full control:

• All infrastructure parameters
• For platform engineers or specialized needs

This acknowledges that not everyone comes to the platform with the same goals.

Making Standard Paths Faster

One approach that appears in platform engineering writing⁶: make the golden path fast, make deviation possible but slower.

Following standard patterns might take minutes. Requesting custom infrastructure might require architectural review and take days.

This nudges toward standards without blocking exceptions.

Preview Environments

Vercel³ automates this completely:

PR #42 opened
  → Deployed to preview-pr-42.vercel.app
  → URL commented on PR

PR merged or closed
  → Preview environment deleted

Internal platforms can implement similar patterns using namespace isolation in shared clusters.

Composition Over Custom Building

Looking across implementations, most platform descriptions emphasize orchestrating existing tools:

• GitHub Actions for CI/CD
• Prometheus or Datadog for monitoring
• Managed databases from cloud providers

Rather than building custom versions of commodity tools.

Starting Simple, Adding Complexity

The documented implementation pattern tends to be:

1. Build minimal template
2. Launch to small group
3. Gather feedback
4. Add optional complexity
5. Broader rollout

Though whether teams actually follow this sequence or jump to comprehensive solutions is variable.

Common Elements

Across various platform implementations, certain patterns recur:

Three-tier abstraction: Simple default, configurable middle tier, full control for specialists.

Shared development infrastructure: One shared cluster for development, dedicated clusters for production or special cases.

Progressive disclosure: Hide complexity by default, make it available on request.

Automated lifecycles: Environments tied to git workflow rather than manual selection.

Cost awareness: Show estimated costs before provisioning.

What These Patterns Address

These approaches seem aimed at similar problems:

• Supporting many developers without proportionally growing platform teams
• Reducing time from "I have an idea" to "I have a running service"
• Balancing standardization with flexibility
• Making costs visible

How well they work depends on organizational context, but the patterns show up often enough to be worth examining.

References

1. Backstage Software Templates - backstage.io/docs/features/software-templates/

2. Heroku Review Apps and Pipeline Promotion - devcenter.heroku.com/articles/pipelines

3. Vercel Preview Deployments - vercel.com/docs/deployments/preview-deployments

4. AWS Proton Environment Templates and Strategies - docs.aws.amazon.com/proton/latest/userguide/ag-environments.html

5. GitHub Codespaces Configuration and Machine Types - docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration

6. CNCF Platform Engineering Maturity Model - tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/

Tags:

Enjoyed this post? Give it a clap!