Building and Scaling a Platform with Project-as-a-Service

Building and Scaling a Platform with Project-as-a-Service - InfoQ

InfoQ Homepage News Building and Scaling a Platform with Project-as-a-Service

Culture & Methods

QCon San Francisco (Nov 16-20): Deep technical sessions. Peer conversations that change how you think.

Building and Scaling a Platform with Project-as-a-Service

Jun 11, 2026 4 min read

by

• Ben Linders

#### Write for InfoQ

Feed your curiosity.

Help 550k+ global

senior developers

each month stay ahead.

Get in touch

Listen to this article -

0:00

Audio ready to play

Your browser does not support the audio element.

Normal

1.25x

1.5x

Like

new dropdown rading list

• Reading list

When a platform started with total developer autonomy, teams felt overwhelmed and ended up solving the same problems in completely different ways, Jerry van Hulst and Marcel Kerker showed in their presentation Ghost in the Platform at KubeCon & CloudNativeCon Europe . They shifted to enablement over support, working together with teams intensively, and helping teams feel confident and capable, turning the right way into being the easiest way.

In 2017, they started with a small team building an OpenShift proof of concept. Their initial philosophy was total developer autonomy, Van Hulst explained:

We provided the platform, and developers were responsible for the entire lifecycle.

By 2019, early adopters were thriving, but as they tried to move beyond that, they hit major growing pains. One was high cognitive load; early users were enthusiasts, but newer teams felt that the learning curve was way too steep. They found themselves overwhelmed by "Kubernetes tax", spending more time managing the platform than actually writing code.

Another growing pain was the fragmentation of knowledge: they didn’t offer teams a lot of standardization, and teams were solving the same problems, like logging or ingress, in completely different ways, Van Hulst explained:

It was the "Wild West" even within the same cluster, which made it a headache for us to support and for teams to run.

They realized that giving everyone total freedom was actually slowing them down, and they needed to move toward a more "paved road" approach.

Their current platform has a strong automation-first philosophy, which also applies to the onboarding journey, Van Hulst said. Their Project-as-a-Service operator offers teams the means to create their environments with one simple YAML file. It includes most of what teams need to get started on the platform, from namespaces and RBAC to resource quota. To enable your developers and empower teams, the philosophy is to prioritize enablement over support, Kerker said. Instead of just functioning as a helpdesk that solves support tickets, their ultimate goal is to build genuine self-sufficiency within engineering teams:

We want them to feel confident and capable.

With over 99+ DevOps teams, scaling knowledge is a challenge. They tackle this by fostering Communities of Practice where teams learn from each other, Kerker said. To keep everyone aligned and inspired, they host a regular Container User Group (CUG) to demo new platform features, alongside larger Containerization Days featuring plenary sessions and external speakers to explore emerging tech.

For hands-on upskilling, they offer targeted, self-paced workshops covering essentials like Tekton, ArgoCD, Identity Access Management, RightSizing, and Kustomize, Kerker said.

Kerker mentioned that their most impactful initiative is the Accelerator Hackathon:

Rather than just handing over documentation, our platform experts sit side-by-side with a development team for a full day. We roll up our sleeves and work together to fast-track their first app onto the platform. It’s hands-on, highly collaborative, and the best way to turn enablement into immediate results.

Their focus is on reducing cognitive load for developers and making their platform even smarter, Kerker said. They are going to double down on their Golden Path, making the "right way" the easiest way to build software. They are planning deep integrations into Backstage, and extending their CI/CD starters:

We want developers to have everything they need right out of the box.

They are also integrating AI to streamline operations by implementing AI-driven auto-answers for ChatOps and support tickets, Kerker explained:

By automating the resolution of repetitive questions, we give developers instant help, while freeing up platform engineers to focus on high-value enablement instead of basic support.

What’s next is determined by the community, Kerker said. They prioritize new features requested by users, and keep listening closely to development teams to ensure they are building the capabilities that actually solve their day-to-day challenges, Kerker concluded.

InfoQ interviewed Jerry van Hulst and Marcel Kerker :

InfoQ: What were the growing pains of your platform?

Jerry van Hulst : The onboarding process was a manual, high-touch process to roll out new environments. Between us prepping the clusters and developers manually configuring their apps, it took forever for a team to actually start delivering value on the platform.

Marcel Kerker : We shifted our strategy to focus on enablement. We started doing massive amounts of knowledge sharing with the DevOps teams. Our main goal became to completely unburden the developers—removing any friction and making the onboarding process onto the platform as incredibly easy and seamless as possible. We didn’t just give them a platform; we held their hands and guided them onto it.

InfoQ: What have you learned?

Van Hulst : Coming from an infrastructure background, my old mindset was: ’If I gave you access to the server, my job is done.’ But I learned that in the cloud-native world, access isn’t enough. If I give a developer a namespace but they have to spend three days configuring ingress and CI/CD, I haven’t really helped them. My personal lesson is that my job isn’t just to provide infrastructure, it’s to remove the friction that stops code from reaching production.

Kerker : I’ve learned that to make a platform successful, you have to relentlessly focus on your developers’ needs and always keep listening to their feedback. Hand in hand with that, I’ve learned that standardization is the absolute key to adoption. If every single team has to figure out the plumbing themselves, adoption grinds to a halt. By standardizing our processes, we remove that friction, prevent teams from reinventing the wheel, and make the platform significantly easier and more intuitive to embrace.

main wrapper for authors section

About the Author

section title

main wrapper for each author

#### Ben Linders

Show more

Show less

#### This content is in the Culture & Methods topic

##### Related Topics:

• Culture & Methods

• DevOps

• SaaS

• YAML

• Platform Engineering

• Teamwork

• Artificial Intelligence

• Hackathons

• Platforms

• Cloud

• Containers

• Kubernetes

• learning

• Related Editorial

• Related Sponsors Build Best-of-Breed Apps with Agentic AI -- Infused with Architectural Guardrails for Deterministic Outcomes

• Related Sponsor Copilots make one developer faster. WaveMaker makes 10 squads consistent. Bring architectural governance and predictable outcomes across skill levels. Try WaveMaker AI .

The InfoQ Newsletter

A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example

We protect your privacy.