You Don't Need Platform Engineering. You Need Paved Roads
A lot of teams reach for platform engineering before they have the scale to justify it. Most do not need an internal platform team. They need a few opinionated defaults that remove repeatable friction.
Platform engineering is becoming the new management-approved way to sound serious about developer productivity.
Someone reads a few case studies from large companies. A conference talk mentions internal developer platforms. Suddenly a team of twenty people starts discussing service catalogs, golden paths, and self-service infrastructure as if they are already operating at the scale of Spotify or Uber.
Early and mid-stage companies usually do not have a platform engineering problem. They have a repetition problem. The same setup work keeps showing up across projects, nobody owns the defaults, and engineers waste time solving the same boring problems in slightly different ways.
That does not require a platform org. It requires paved roads.
Paved roads beat platform theater
A paved road is simple. It is the easiest approved way to do a common thing well.
That might be:
- one reliable service template
- one deployment path
- one standard auth approach
- one logging and monitoring setup
- one sane CI pipeline
The point is to stop making every team reinvent the same plumbing.
Most “platform engineering” efforts start with abstraction before they have enough repeated pain to justify it. Teams build portals, wrappers, and internal products before they have even agreed on the basic path for shipping a service. That is backwards.
If engineers still need a Slack archaeology session to figure out how to deploy, your problem is not the lack of an internal platform. Your problem is the lack of a clear default.
The anti-pattern: building an internal platform too early
Premature platform work usually follows the same script.
Leadership notices inconsistent delivery across teams. Developers complain about friction. Instead of fixing the top five recurring pain points, the company decides to “invest in platform.” That sounds strategic. It often creates a second-order mess.
You create another product to maintain
An internal platform is still a product. It needs ownership, support, documentation, and prioritisation. If your company struggles to maintain customer-facing product quality, it probably will not magically excel at internal product management.
You abstract unstable decisions
Teams build reusable tooling around processes that are still changing every month. The result is a polished layer on top of unresolved confusion. Now the mess is harder to unwind because it has an interface.
You centralise too early
A small team can move fast by making local decisions. A weak platform layer can turn that into dependency hell. Every change becomes a request to the platform team.
You confuse standardisation with indirection
Standardisation is useful. Indirection is not automatically useful. If your template, wrapper, or portal makes a common task slower to understand, you have created ceremony.
Start with the work that repeats
Do not begin with org charts or platform narratives. Begin with recurring engineering chores.
Look for things that appear in every project:
- bootstrapping a new service
- setting up environments and secrets
- wiring auth
- configuring observability
- handling background jobs
- defining deployment checks
If five teams are solving the same problem five different ways, that is where a paved road belongs.
At IndieStudio, this is usually where the highest-return work sits: removing the same avoidable setup friction that keeps stealing time from delivery.
Build one boring path that people will actually use
Good paved roads are opinionated
“Flexible” defaults are usually not defaults. They are disguised ambiguity.
Pick a stack. Pick the CI pattern. Pick the deployment path. Pick the logging approach. If the company is not ready to make those decisions, it is definitely not ready for platform engineering.
Good paved roads are faster than the custom route
If following the standard path takes longer than going rogue, engineers will go rogue.
The paved road has to reduce effort in real terms: less setup, fewer decisions, less debugging, and safer deploys.
Good paved roads stay close to the underlying tools
Do not hide everything behind a magical internal abstraction layer unless you have to. Thin templates and clear scripts age better than overbuilt platform wrappers. Engineers should still understand what is happening underneath.
The practical rollout most companies can handle
You do not need a reorg to do this properly.
Step 1 - Identify the top three repeated pain points
Not twenty. Three.
Ask engineers where time gets wasted before meaningful feature work starts.
Step 2 - Choose defaults with real constraints
Do not publish a menu. Publish a route.
For example: this is the default web service template, this is the deployment pipeline, this is the monitoring package, this is how secrets are handled.
Step 3 - Make the happy path genuinely smooth
The standard route should feel like relief, not governance. Create templates, scripts, starter repos, and docs that get someone from idea to running service quickly.
Step 4 - Allow exceptions, but make them explicit
Paved roads are not handcuffs.
Sometimes a team should diverge. That is fine. But divergence should be a conscious trade-off.
Step 5 - Maintain the road
This is the part companies skip.
Defaults decay. Docs drift. Scripts break. A paved road without maintenance turns into the exact friction it was meant to remove.
If nobody owns the standard path after launch, do not bother launching it.
When real platform engineering does make sense
There is a point where a company genuinely needs more than paved roads.
Usually that happens when:
- many teams are shipping independently
- infrastructure patterns are stable enough to standardise deeply
- self-service delivery is blocked by scale, not by basic confusion
- internal tooling has enough users and repeatable demand to justify product-level ownership
That is when a platform function can create real leverage. But by then, the groundwork already exists.
Stop copying big-company language
This is the strategic mistake underneath all of this.
A lot of smaller companies borrow the vocabulary of larger engineering organisations long before they have the operating shape that made that vocabulary useful. Platform engineering, developer portals, internal platforms. The words arrive first. The need arrives much later, if at all.
That gap is expensive.
If your team is still fighting basic setup inconsistency, slow onboarding, fragile deploys, or unclear defaults, skip the platform branding exercise. Fix the roads.
The goal is not to look sophisticated. The goal is to make common engineering work faster, safer, and less dependent on tribal knowledge. That is less glamorous than announcing a platform initiative. It is also far more likely to work.
At IndieStudio, we usually help teams standardise the highest-friction delivery paths first - templates, deployment flows, environment setup, and operational defaults - before anyone talks about internal platforms. Most companies do not need more architecture language. They need fewer avoidable decisions.