Internal Developer Platform

Why I Built This

Over the last 15+ years, I’ve worked with engineering teams of different sizes, technologies and maturity levels. Moreover I also got an opportunity to work in customer facing roles where I directly interacted with C-Suite executives.

• The tech stack changed.
• The cloud providers changed.
• The CI/CD tools changed.
• Processes, culture and philosophy around Enginering changed.

But one thing stayed remarkably consistent.

Developers rarely spent most of their time writing code.

Instead, they spent time waiting.

Over the years, I realised these weren’t isolated problems. They were all different forms of engineering friction. That observation became the starting point for this project.

The problem I wanted to solve

Most engineering organizations already invest heavily in tools.

• Cloud platforms
• CI/CD
• Monitoring, Logging, Tracing (Telemetry)
• AI coding assistants
• Developer portals
• Project Management Platforms
• Paid Testing tools….

Yet developers still ask the same questions.

“How do I run this locally?”

“Can someone give me test data?”

“Who owns this service?”

“It works on my machine.”

“Let’s deploy and see.”

The problem wasn’t the lack of tools. The problem was everything between those tools. I wanted to reduce that friction.

Patterns I repeatedly observed

These are not theoretical problems. They are patterns I encountered repeatedly throughout my career.

Environment Gap

• Local development rarely behaves like production.
• Developers spend hours configuring dependencies, infrastructure and credentials before they can make their first meaningful change.

Knowledge Gap

• Critical architecture decisions often live inside conversations instead of repositories.
• When experienced engineers become the documentation, onboarding slows and delivery becomes dependent on tribal knowledge.

Data Gap

• Developers need realistic data.
• Using production data isn’t an option.
• Using overly simplified synthetic data often hides the problems that appear later in production.

Validation Gap

• API compatibility, infrastructure validation and deployment checks frequently happen too late in the delivery pipeline.
• Developers discover problems after integration instead of during development.

AI Context Gap

• AI coding assistants have become incredibly capable. But during my own experiments, I noticed something interesting.
• The quality of AI-generated changes depended less on the model itself and more on the engineering context available to it.

Architecture decisions.

Repository conventions.

Deployment rules.

API contracts.

Without that context, AI spends more time guessing than assisting.

My Approach

Instead of building another developer portal, I wanted to build a platform that quietly removes repetitive engineering work.

My design principle was simple:

The easiest path should also be the correct engineering path.

Developers shouldn’t have to remember dozens of engineering practices. The platform should make them happen automatically.

Instead of this:

1
2
3
4
5
6

Configure
Search
Request Access
Wait
Debug
Repeat

I wanted the workflow to become:

1
2
3
4

Clone
Develop
Validate
Ship

What I Built

This project explores a modern Internal Developer Platform focused on reducing engineering friction through automation.

The platform includes capabilities such as:

• Self-service development environments
• Environment as Code
• Production-like test data provisioning
• Automated API contract validation
• Service discovery
• Standardized developer workflows
• AI-ready repository context using AGENTS.md
• Built-in observability and feedback

Rather than introducing more processes, the platform attempts to remove manual decisions from the software delivery lifecycle.

Measuring Productivity Instead of Assuming It

One lesson I’ve learned is that productivity shouldn’t be measured by lines of code or deployment frequency alone.

Instead, I prefer measuring engineering friction.

Some examples include:

Reducing these delays improves developer experience far more than introducing another tool.

Engineering Productivity Experiment

To validate the approach, I designed a repeatable measurement framework that compares engineering workflows before and after introducing platform capabilities.

The numbers below are from one representative implementation and are intended to demonstrate the measurement methodology rather than serve as universal benchmarks.

The important outcome isn’t the numbers themselves.

It’s establishing a repeatable way to measure engineering friction and validate whether platform investments actually improve developer workflows.

What Changed with AI

When I started my career, Platform Engineering focused almost entirely on serving developers. Today, platforms have another consumer as AI agents.

Developers need:

• environments
• data
• feedback

AI agents need:

• context
• architecture
• constraints
• conventions

That realization significantly influenced this project.

Instead of treating AI as another coding tool, I began treating it as another engineering consumer that benefits from structured platform metadata.

What I Learned

Looking back across 15+ years of engineering, the biggest productivity improvements rarely came from writing code faster.

They came from removing everything that prevented engineers from writing code in the first place.

If a task is repeated every day, automate it.

If knowledge is repeatedly shared in chat, document it.

If validation can happen earlier, move it left.

If AI lacks context, provide it.

The goal isn’t to build more tooling.

It’s to build an engineering platform that quietly removes friction so developers can focus on solving business problems instead of navigating operational complexity.