Internal Platforms vs. Ad-Hoc Tooling: Which Developer Experience Actually Wins

| 6 min read |
developer-experience platform-engineering devops productivity

A comparison of two approaches to developer experience -- purpose-built internal platforms versus the organic tooling that teams build for themselves -- and when each one actually delivers.

Quick take

Stop building internal platforms because a conference talk told you to. If your developers are already shipping fast with scripts and Makefiles, a shiny platform might just slow them down. Platform DX only wins when organic tooling has genuinely collapsed under its own weight.

I’ve built internal platforms. I’ve also inherited codebases where a pile of shell scripts and a well-maintained Makefile outperformed every “developer portal” I’d seen at the time. The difference between those outcomes was never the technology. It was whether the team actually needed a platform or just needed their existing tools to stop breaking.

At the fintech startup, our stack grew from one service to about fifteen in under a year. We hit a point where onboarding a new engineer meant a full day of tribal knowledge transfer: which repo to clone first, which env vars to set, which Docker Compose file was current. The ad-hoc scripts that got us through the first year became the bottleneck. That’s when a platform starts to make sense. Not before.

The Two Approaches, Honestly

Ad-hoc tooling is what every team starts with. Makefiles, shell scripts, a README that someone updates when they remember. It’s fast to create, easy to understand, and perfectly tuned to the team that wrote it.

An internal platform is what you build when the ad-hoc approach stops scaling. A curated set of tools, templates, and workflows that standardize the path from code to production.

In 2019, the industry conversation heavily favored platforms. I think that framing skips the part where most teams aren’t ready for one.

Where Ad-Hoc Tooling Wins

Small teams. Early-stage products. Anything where the domain is still shifting.

When I was at Dropbyke in Seoul building our mobility backend, we had four engineers. A Makefile with targets for build, test, deploy-staging, and deploy-prod covered about 90% of our workflow. Total maintenance cost: maybe an hour a month. Everyone understood every line because everyone had written at least one target.

Ad-hoc tooling wins when:

  • The team is under ten engineers and everyone knows the stack.
  • Requirements change weekly, so a rigid platform would just get in the way.
  • The “platform” would have exactly one consumer team. That’s a library, not a platform.
  • You can still onboard a new engineer in under two hours with a README and a pair programming session.

The honest advantage is speed and ownership. Nobody files a ticket to change a Makefile. Nobody waits for “the platform team” to prioritize a feature.

Where Ad-Hoc Tooling Breaks Down

It breaks down at the seams. Not within one team, but across teams.

The symptoms are consistent. I’ve seen them at every company past about fifteen engineers:

  • New hires take days to get a working local environment because every team’s setup script assumes different things.
  • “Works on my machine” becomes a weekly standup topic.
  • Three teams have three different CI configs that do roughly the same thing with slightly different bugs.
  • Nobody knows how to deploy the service they inherited from the team that left.

The failure mode isn’t that any single script is bad. It’s that the collection of scripts has no coherence. Each one optimizes for its author’s context, and that context drifts.

Where a Platform Actually Earns Its Keep

A platform earns its keep when it removes decisions that slow people down without removing decisions that matter.

Good platform DX looks like this:

  • platform init scaffolds a new service with CI, monitoring, and deployment already wired up. The developer writes business logic on day one.
  • git push triggers a pipeline that builds, tests, and deploys to staging. No YAML archaeology required.
  • Logs, metrics, and traces are correlated by default. When something breaks at 2am, the on-call engineer doesn’t need to be an expert in the observability stack.

Bad platform DX looks like this:

  • A portal with a service catalog that nobody updates.
  • Mandatory migration to “the platform way” with no clear improvement in daily workflow.
  • A platform team that ships features on their own roadmap instead of fixing the paper cuts developers actually report.

I’ve been on an EF (Entrepreneur First) batch this year, building Decloud, and one thing the startup environment hammers home is this: your internal customers are just as fickle as external ones. If the platform isn’t obviously better than what developers already have, they will route around it. Every time.

The Comparison That Matters

Here is how I think about the tradeoff in practice:

Onboarding time. Ad-hoc: depends entirely on documentation quality, which is usually poor. Platform: can be excellent if platform init and golden paths work. Can be terrible if the platform itself needs onboarding.

Speed of change. Ad-hoc: instant for the team that owns the script, impossible for everyone else. Platform: slower to change but the change applies everywhere.

Reliability. Ad-hoc: varies wildly per team. Platform: consistent baseline, but a platform bug affects everyone simultaneously.

Cost. Ad-hoc: hidden in every team’s sprint. Platform: visible headcount on a dedicated team. Leadership often prefers the visible cost, which is ironic because it’s usually higher.

Autonomy. This is the one people underweight. Developers care about autonomy. A platform that takes away the ability to customize a build step or add a deployment hook will face resistance no matter how polished it is. The best platforms I’ve seen treat defaults as suggestions and overrides as first-class features.

My Rule of Thumb

If you have fewer than three teams consuming shared infrastructure, invest in better scripts and a good README. Seriously. A Makefile with ten well-named targets and a one-page setup guide will outperform a half-built platform every time.

If you have more than three teams and you’re seeing the same problems solved differently in each one, start building a platform. But start with the one workflow that causes the most pain, not with a portal and a service catalog.

At the fintech startup we started with deployment. Just deployment. One command to deploy any service to staging, with automatic rollback if health checks failed. That single workflow converted the skeptics faster than any roadmap slide could have. Then we added CI standardization. Then observability. Each step earned trust before the next one started.

Where platform teams actually fail

Most internal platforms fail not because the technology is wrong but because the team builds what they find interesting instead of what developers need. I’ve been guilty of this. At one point I spent two weeks building a slick CLI for environment management when the actual pain point was that our staging database kept running out of disk space.

If you take one thing from this post: talk to your developers before you build anything. Sit with them. Watch them work. The friction you need to fix is almost never the friction you assumed.

Good DX – whether it comes from a platform or a pile of scripts – is measured by one thing: how fast a developer goes from idea to running code in production, without fear. Everything else is details.