top of page

Building a Great Internal Platform Starts with the API

At SOOCon23, Abby Bangser delivered an insightful talk titled "Building a Great Internal Platform Starts with the API." Drawing on her extensive experience in platform engineering, Abby emphasised how adopting an API-first mindset can transform internal platforms from clunky ticket-driven systems into dynamic, scalable products that empower developers and simplify platform team operations.


I’m writing this summary now, as I frequently find myself sharing the video with customers and community members. Not everyone enjoys watching videos, so I wanted to distil all the key takeaways into written form.


Check out the talk recording here, and keep reading for the summary:

Building a great platform starts with APIs (Abby Bangser at SOOCon23)

The Evolution of Internal Platforms

Abby began by contextualising internal platforms within the evolution of software delivery models. The journey from Dev and Ops separation to DevOps helped empower teams and speed up delivery, but introduced challenges at scale. As organisations grow, duplicated efforts and inconsistency can make operations inefficient and frustrating.


This is where internal platforms offer standardised services and tooling to reduce cognitive load for application developers. However, not all platforms are created equal. Abby identified three common patterns: highly customised ticket-driven platforms, cloud-native self-service environments, and templated solutions using tools like Terraform or Helm. Each has tradeoffs in customisation, usability, speed, and maintainability.


The False Dilemma and the Power of the API

A recurring theme in the talk was that teams often feel forced to choose between flexibility and control. Abby challenged this "false dilemma," advocating instead for internal platforms to offer both customisation and scalability through thoughtfully designed and composable APIs.


An API in this context, Abby explained, serves as a contract between the platform and its users. By codifying expectations, it reduces ambiguity and allows for seamless separation between producers and consumers.


Importantly, APIs enable each team to work independently, including evolving their implementations while also allowing multiple user interfaces without high overhead. Whether users want to access these APIs via CLI, UI, or chatbots, developers can engage with the platform on their terms.


The False Dilemma and the Power of the API
The False Dilemma and the Power of the API

Platform as Product: Shifting the Mindset

Moving beyond technology, Abby stressed the importance of treating internal platforms as products. This means:


  • Focusing on user experience and iteratively improving based on developer feedback.

  • Providing clear, discoverable catalogues of offerings.

  • Owning roadmaps and prioritising features.

  • Reducing manual toil and non-value-added work.


This mindset shift helps platform teams avoid becoming bottlenecks and instead positions them as enablers of fast, reliable software delivery.


Getting Started with an API-First Platform Using Kratix

Abby acknowledged that moving toward product thinking and APIs can feel daunting, especially for busy platform teams. To make this actionable, she showcased Kratix, our open-source framework for building extensible internal platforms.


Kratix introduces the concept of "Promises," which bundle Kubernetes Custom Resource Definitions (CRDs) and workflows to implement on-demand platform services. Promises allow teams to define APIs, validation rules, and business logic while delegating execution to configurable workflows.

Through a live demo, Abby showed how easy it is to:


  • Start with designing the API users need (e.g., focus on the API and simply create tickets or send notifications about the request).

  • Evolve that API into a more useful infrastructure management service (e.g., extend implementation to automate database provisioning).

  • Implement additional business processes, including request validation, asynchronous processing, and notification to relevant parties via Slack or Jira.

  • Benefit from the ability to swap out or enhance backend implementations without changing the API contract.


This pragmatic approach enables platform teams to introduce consistency, reduce ad hoc requests, and develop muscle memory for API-driven operations.


Getting Started with an API-First Platform Using Kratix
Getting Started with an API-First Platform Using Kratix

Incremental Progress and Evolution Over Revolution

Abby concluded with an important reminder: platforms do not need to be perfect from day one, but changing user experience is expensive.


Starting with an API, even if it initially triggers manual work, creates the foundation for automation and scalability without user experience changes later. By making work visible and creating clean interfaces, teams can escape the trap of perpetual toil.


She urged platform engineers to embrace evolutionary change while choosing tooling, such as Kratix, that supports future growth. In doing so, teams can build internal platforms that strike a balance between governance, customisation, and developer experience.


Final Thoughts

Abby's talk was a practical and inspiring call to action for platform engineering teams. Rather than getting stuck between rigid frameworks and uncontrolled self-service, she showed how API-first thinking and incremental improvement can deliver the best of both worlds.


This talk serves as a roadmap for organisations on the journey to effective internal platforms: focus on the API, treat your platform as a product, and use tools like Kratix to scale your capabilities over time.


Comments


bottom of page