Platform engineering’s most critical first decision

January 03, 2025

Most platform engineering initiatives make their most consequential choice in the first few weeks, often without noticing: what to build first. The tempting answer is a developer portal, because it is visible and easy to demo. Usually the better answer is the backend of the platform: the automation that actually creates services, provisions environments and ships code. A portal can come later and sit on top of it.

What platform engineering actually is

Platform engineering is the practice of building an internal developer platform (IDP): a set of self-service capabilities that let product teams create, deploy and operate software without filing tickets or becoming infrastructure experts. Its core building blocks are:

Golden paths: opinionated, supported ways to do common tasks, such as a new service with its pipeline, logging, secrets handling and security scanning already wired in.
Self-service: developers trigger these paths themselves through an API, a CLI, a Git-based workflow or a portal, instead of waiting in an ops queue.
Guardrails: security, cost and compliance policies applied by default rather than checked manually in review.

The goal is lower cognitive load for product teams and consistent, auditable delivery for the organization. A platform is not a renamed ops team or a single tool.

Why the first decision matters

Platforms are shaped by their first release. It defines the team's skills, the architecture and, most importantly, what developers believe the platform is for. If the first thing they see is a portal whose buttons open tickets or link to wiki pages, they conclude the platform is a catalog, and that impression is hard to reverse. If the first thing they get is a working golden path that replaces days of waiting with a self-service command, adoption tends to follow.

There is also an architectural reason. The automation layer holds the hard logic: infrastructure configuration, access control, environment lifecycle, deployment orchestration. Interfaces are interchangeable; that logic is not. Behind a clean API it can serve a CLI, a pull-request workflow and a portal without duplication. Retrofitted behind a UI built first, it ends up tangled with that UI, which is exactly the kind of technical debt that slows every later feature.

The options and their trade-offs

Portal first

Stand up a developer portal such as Backstage, the open-source framework originally built at Spotify, with a service catalog, documentation and ownership data. Benefits: quick visibility and one place to find who owns what. Costs: a portal without automation behind it changes little in daily work, and an open-source portal is a product you maintain, with plugins, upgrades and catalog data quality to look after. Choose this only if discoverability and ownership are your real bottleneck.

Backend first

Build the orchestration layer: service templates, reusable infrastructure-as-code modules, standard CI/CD pipelines, environment provisioning and policies as code, exposed through an API or CLI. Benefits: it removes real toil and supports any future interface. Costs: it is less visible early, so progress must be communicated deliberately, and abstractions may get designed for problems you do not have yet.

One thin golden path, end to end

This is the option we recommend: backend first, narrowed to a single path. Pick the workflow that hurts most, typically creating a new service or getting a production-like environment, and automate it completely, from repository template to a running, monitored deployment. Expose it through the interface developers already use, usually Git and the command line. Add a portal once you have several paths worth surfacing. You keep the structural advantage and still ship something useful within weeks.

How to decide

Team size and structure. A platform pays off when several teams repeat the same infrastructure work. With one or two teams, shared templates may be enough.
Product needs. Strict compliance, many environments or frequent new services justify more automation than a single web app on a managed host.
Existing tooling. Inventory your CI, cloud accounts, runtime (Kubernetes, a PaaS or plain VMs) and infrastructure code. The first version should compose these, not replace them.
Build vs adopt. Use managed services for commodity layers such as clusters, databases and CI runners, open-source projects where they fit and you can afford upkeep, and build in-house only the glue that encodes your own conventions. The trade-offs described in owning your code vs using a platform apply here too: every adopted tool trades speed now for dependency later.
Skills on hand. Portal plugins need frontend engineers; orchestration needs infrastructure and API skills. Start where your team is strong.

Treat the platform as a product

The platform's users are your developers, and they can usually route around it. That makes voluntary adoption the honest measure of success. In practice:

Give the platform an owner who acts as its product manager: interviews teams, keeps a roadmap, prioritizes by developer pain and says no.
Record a baseline and track it: time to create a new service, time to first deployment for a new engineer, waiting time on infrastructure requests, plus the standard DORA delivery metrics.
Earn adoption instead of mandating it. If teams avoid a golden path, treat that as a bug report.
Provide escape hatches. A golden path should be the easiest route, not the only one.
Document it like an external product: quick starts, examples, a changelog.

The first 90 days

Days 1 to 30: discover. Map how code gets from commit to production, interview several teams, collect baseline numbers and list existing tools. Choose one golden path and define what "done" means for it.
Days 31 to 60: build the thin slice. Create the service template, pipeline, infrastructure module and deployment flow, with security scanning, secrets management and observability built in. Pilot it with one or two willing teams and fix what they hit.
Days 61 to 90: harden and expand. Write documentation, define the support model, compare results with the baseline, onboard the next teams and decide on the next paths, including whether a portal is now justified.

This follows the same logic as setting up software development effectively: standardize the delivery pipeline early and make it automatic. At 4K-Soft, CI/CD and automated testing are part of every project from the start, because retrofitting them later always costs more.

Common mistakes

Treating a portal installation as the platform.
Building for imagined scale, such as wrapping every cloud service up front.
Renaming the ops team "platform" while keeping the ticket queue.
Mandating adoption, then mistaking compliance for value.
Underestimating the upkeep of open-source components: upgrades, security patches, plugin drift.
Building a golden cage with no supported way to deviate.

When a small company does not need a platform team yet

With a handful of engineers, one product and managed hosting that works, a dedicated platform team is premature. A shared pipeline template, infrastructure as code in one repository, a short "how we ship" guide and one engineer owning the tooling part-time will do more. Revisit it when the signals appear: several teams duplicating pipeline and infrastructure work, new engineers taking weeks to ship their first change, environment requests waiting in queues, or security settings drifting between services. Those are the problems a platform solves; without them it is overhead. When growth brings them, plan the platform as part of your scaling strategy, alongside hiring and architecture.

Whether you are planning a platform or just want a consistent delivery pipeline, start small: one painful workflow, automated end to end, measured against today's baseline. 4K-Soft brings 10+ years of offshore mobile and web development and covers the full cycle, from idea and design to support and scaling, under Time & Material, fixed price or dedicated team models. For a second opinion on where your platform should start, contact our team.