> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Simplified Access
> How to build developer-friendly internal platforms with CLI, templates, scaffolding, and APIs to simplify access, enforce best practices, and improve developer experience and adoption.
Welcome. This lesson explains how to build simplified access for developer platforms: user-friendly CLIs, reusable templates, and scaffolding that deliver code, access, and repeatability. The objective is to improve developer experience (DX) so teams adopt the platform and ship value faster — a core goal for platform engineering.
This page covers:
* Why DX matters and the forces driving it in 2025
* Common developer pain points
* Platform goals and core design principles
* CLI patterns and examples
* Template systems and parameter validation
* Ecosystem tooling and strategic decisions
* Error handling, observability, and measuring success
Four macro drivers making DX non-negotiable in 2025:
* Cognitive load crisis — developers juggle many tools and contexts.
* Speed expectations — teams expect services created in minutes.
* Self-service demand — infrastructure provisioning without tickets.
* Consumer-grade UX — intuitive, mobile-like simplicity.
At Sparkle Pony Ranch (SPR), multiple roles must be enabled at scale: Swati (ops), Allan (infrastructure), and Phong (developer). The platform must reduce friction, provide predictable outcomes, and let teams deliver value without wrestling infrastructure.
Common developer struggles:
* YAML complexity — long manifests and multi-step thought processes deter productivity.
* Tool sprawl — many CLIs and CLIs + GUIs elevate cognitive load.
* Documentation maze — scattered READMEs and wikis slow onboarding.
* Time wasted — developers spend significant time on infra rather than features.
Platform goals
* Make infrastructure simple, discoverable, and opinionated.
* Show basics first and reveal advanced options on demand (progressive disclosure).
* Provide “golden paths”: opinionated defaults for the most common use cases.
* Embrace declarative interfaces so developers declare what they want, not how to achieve it.
Example objective at SPR: one command to create a Pony service with monitoring, CI/CD, security, and operational defaults included — no prior Kubernetes knowledge required. That one-command flow smooths onboarding and offboarding.
Design "CLI-first" and API-first flows. A well-crafted CLI complements the UI and APIs: it is fast, scriptable, and works inside terminals, CI pipelines, and IDEs. Prioritize consistency across CLI, web UI, and programmatic APIs so templates and operations behave the same regardless of how they're invoked.
Why keep a CLI?
* Speed and precision for power users.
* Automation-friendly for scripts and pipelines.
* Works in low-bandwidth or remote SSH sessions.
* Complements GUIs and underlying APIs.
Common CLI patterns
* Subcommand structure (verb object), e.g. `platformctl create service`
* Rich, structured output (colors, progress bars, JSON output)
* Built-in help and shell auto-completion
* Support for structured config input (YAML/JSON)
* Orchestrated flows and examples for frequent tasks
Example CLI hierarchy and usage:
```bash theme={null}
# CLI structure (example)
platformctl
├─ create (service, database, environment)
├─ deploy (app, infrastructure)
├─ status (cluster, services, pipelines)
└─ debug (logs, traces, metrics)
```
```bash theme={null}
# Example usage
platformctl create service rainbow-spawner
platformctl deploy app rainbow-spawner --env production
```
Templated creation examples:
```bash theme={null}
# Create a service from a template
ponyctl create service rainbow-spawner \
--template nodejs-api \
--team magical-creatures
# Create a database with parameters
ponyctl create database pony-analytics \
--type postgres \
--size medium \
--backup-schedule daily
```
Templates codify best practices — speed, security, consistency, and knowledge transfer — and allow senior engineers to encode organizational standards into reusable scaffolds.
Template types and a simple reference table
| Template type | Purpose | Example |
| - | - | - |
| Service templates | Bootstraps application code and service manifest | `nodejs-api`, `go-http-service` |
| Infrastructure templates | Provision backing infra (databases, caches) | `postgres-medium`, `redis-cluster` |
| Pipeline templates | Standard CI/CD pipeline definitions | `github-actions-nodejs`, `tekton-k8s` |
| Documentation templates | Auto-generated README and runbook scaffolds | `service-runbook`, `oncall-playbook` |
These templates should chain together: a service template can reference an infra template and a pipeline template to bootstrap code, deployment, and runbooks in a single flow.
Template system design: balance flexibility with guardrails
* Manifest templates — parameterized Kubernetes YAML or Helm charts
* Parameter schema — JSON Schema for validation and UI generation
* Auto-generated docs — README and runbooks generated automatically
* Hooks — pre/post generation scripts for side effects or scaffolding
Example parameter schema (validates replica counts and environment):
```json theme={null}
{
"type": "object",
"properties": {
"replicas": {
"type": "integer",
"minimum": 1,
"maximum": 10
},
"environment": {
"type": "string",
"enum": ["dev", "staging", "prod"]
}
},
"required": ["replicas", "environment"]
}
```
Policy note: For highly available workloads, set `minimum` to `2` for `replicas`. Ensure parameter schemas reflect organizational constraints (quotas, allowed regions, instance sizes) and map to enforcement checks in CI or admission controllers.
Beyond CLI and templates: provide a web portal, stable APIs, and IDE plugins. All interfaces must call the same backend API so operations behave consistently whether executed from a CLI, UI, or programmatically.
CNCF ecosystem building blocks for DX:
* [Backstage](https://backstage.io/) — service catalog and TechDocs for discovery
* [Helm](https://helm.sh/) — packaging and templating for Kubernetes
* [kubectl](https://kubernetes.io/docs/reference/kubectl/) — a canonical cluster CLI example
* [OpenTelemetry](https://opentelemetry.io/) — observability for traces, metrics, and logs
Strategic options
Decide whether to build custom, adopt CNCF projects, extend existing tools, or contribute back to open source. Backstage is a common pick for a service catalog, but it requires investment to customize and operate.
Error handling — reduce support load by surfacing helpful, actionable errors:
* Clear, concise messages with context
* Suggested next steps and links to runbooks
* Meaningful error codes for automation and analytics
* Deep links to docs or escalation paths
Example improved error and next steps:
How to present the error:
* Error: Resource quota exceeded for `rainbow-spawner` in namespace `magical-creatures`.
* Suggested next steps: check quota status (`kubectl get resourcequotas` or portal), request an increase, or follow the quota runbook.
* Indicate whether small temporary increases may be auto-approved (when policy allows) and provide a link to the policy.
Measuring developer experience success
Track concrete metrics and correlate them to business outcomes.
| Metric | What it measures | Why it matters |
| - | - | - |
| Usage analytics | Who uses the platform, which templates, frequency | Understand adoption and friction points |
| Time-to-first-success | Time from onboarding to first deploy | Measures onboarding effectiveness |
| Developer satisfaction | Surveys, developer NPS | Qualitative signal of platform health |
| Iteration cycles & deployment frequency | Number of deploys / release cadence | Shows delivery velocity improvements |
Collect adoption metrics, failure rates, and correlate platform usage with developer productivity. Product-oriented platform teams should run experiments, collect feedback, and iterate with real users.
Key takeaways
* CLI-first design with consistent APIs and a polished UI is indispensable.
* Template systems reduce friction, enforce best practices, and capture institutional knowledge.
* Intelligent scaffolding (code + infra + pipeline templates) accelerates time-to-value.
* Golden paths and progressive disclosure deliver predictable, low-cognitive outcomes for common tasks.
Final notes
* Offer a portal, a robust CLI, and a well-documented API.
* Use CNCF projects when they fit your needs (Backstage for catalogs, Helm for packaging).
* Bake operational and security controls into self-service flows.
* Continuously gather real usage data and developer feedback; iterate relentlessly.
When developers choose the platform because it simplifies their work, you’ve earned voluntary adoption. Thank you.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.