I Build Developer Platforms for a Living. Then I Built One for a Trampoline. — Bill Gilleran<br>← all writingI Build Developer Platforms for a Living. Then I Built One for a Trampoline.<br>Jun 9, 2026<br>I've spent years working in developer tooling.

I've built internal developer portals.

I've automated infrastructure.

I've created golden paths.

I've spent countless hours helping engineering teams reduce friction and improve the developer experience.

And yet, none of that adequately prepared me for my greatest platform engineering challenge:

Building a platform for a trampoline.

The Initial Requirement

The project started innocently enough.

My kids have a Vuly Thunder Pro 2 XL trampoline.

The trampoline entrance sits roughly 36 inches off the ground.

The official user onboarding process consisted of:

Approach trampoline.

Climb awkwardly.

Hope for the best.

As a father approaching the age where standing up is accompanied by sound effects, I identified an opportunity for improvement.

I needed a better user experience.

Understanding the Users

Every successful platform starts with understanding its users.

In this case, the users were:

Two children.

One trampoline.

One pitsky named Dunkin.

The children wanted easy access.

The trampoline wanted people to stop hanging awkwardly from the entrance.

Dunkin mostly wanted additional elevated surfaces from which to supervise construction activities.

Observability Comes for Us All

One thing I've learned from years in developer tooling, observability, technical support, and platform engineering is that you begin to see the world differently.

You stop looking at systems and start looking at interactions.

You start noticing friction.

You start noticing patterns.

You start asking questions.

Why are users struggling here?

What is causing that behavior?

How can we make the desired outcome easier?

The trampoline platform started because I noticed something small.

Every time someone entered the trampoline, they hesitated.

They climbed awkwardly.

They adjusted.

They figured it out.

Most people would simply accept that as normal.

Instead, my brain treated it like a support ticket.

A recurring issue affecting multiple users.

Severity: Low.

Frequency: High.

Potential for improvement: Significant.

From that point on, the process felt surprisingly familiar.

I observed the system.

I identified the bottleneck.

I looked for patterns.

I gathered data.

I tested assumptions.

I changed course when new information appeared.

What started as "build some stairs" became a surprisingly accurate representation of how many technical problems are solved.

Not through a moment of genius.

But through observation, curiosity, and a stubborn refusal to ignore friction.

The Curse of Pattern Recognition

Engineers often joke that pattern recognition is a superpower.

They're only half joking.

The same instincts that help identify recurring production issues or trace the root cause of an outage also tend to follow us into everyday life.

We notice things.

We connect unrelated ideas.

We see systems where other people see individual objects.

A trampoline becomes an onboarding experience.

A staircase becomes a user journey.

A shoe pile becomes an organizational problem.

A backyard becomes a platform.

This is not always healthy.

But it is remarkably consistent.

Platform Engineering Principles

As the project grew, I began noticing something familiar.

I wasn't building stairs.

I was applying platform engineering principles.

Reduce Friction

Good platforms reduce friction.

Developers shouldn't need to understand Kubernetes internals just to deploy an application.

Kids shouldn't need to perform a gymnastics routine just to enter a trampoline.

The objective was identical.

Make the desired outcome easier.

Create a Golden Path

Platform teams talk constantly about golden paths.

A golden path is the easiest, safest, most obvious route to success.

The platform eventually evolved into exactly that.

Walk up the stairs.

Remove shoes.

Store them.

Turn left.

Board trampoline.

No documentation required.

Self-Service

The best platforms empower users to help themselves.

The platform doesn't require supervision.

The users know exactly what to do.

The system guides them naturally.

This realization was deeply unsettling.

I had accidentally turned a trampoline into a platform engineering exercise.

Technical Support Never Leaves You

Anyone who has spent time in technical support develops a particular habit.

You stop asking:

"What is broken?"

And start asking:

"What experience caused this behavior?"

The platform was never really about making the trampoline easier to access.

It was about understanding why users were struggling in the first place.

Good support engineers know that solving the reported issue is only half the job.

The real goal is removing the conditions that created the issue.

The platform did exactly that.

The problem wasn't that...