“Working Code Wins”: Winning Big with Hackathons and Internal Platforms

At KubeCon, Phill Morton and Abby Bangser delivered a workshop that championed the principle that “working code wins.” Their session showed attendees how to launch an internal platform experience that supports hackathons, developer autonomy, and scalable engineering practices, all grounded in real-world, production-grade tooling.

Drawing on the experience at The Access Group (TAG), the UK’s largest software business headquartered in the UK, Phill and Abby showcased how internal platforms, particularly those powered by Kratix and Kubernetes, can accelerate innovation and enable scalable developer self-service.

Why Hackathons?

Hackathons are often seen as chaotic, caffeine-fueled weekends of experimentation. But Phill and Abby reframe them as an opportunity to test platform readiness and demonstrate the power of working software. Instead of investing in abstract platform designs, they advocate using hackathons as a proving ground: “If you can make your engineers productive in a hackathon, you’ve probably nailed your DevEx.”

In their story, a company-wide hackathon at TAG became the catalyst to build and battle-test an internal platform using Kratix, GitOps principles, and cloud-native tooling. This wasn’t just for show: it was the same platform that hosted the backstage portal, tracked hundreds of projects, and supported three other internal hackathons.

Getting Hands-On with Kratix

The KubeCon workshop used the browser-based tool Instruqt to get attendees hacking immediately. Participants deployed a simple platform service — a Postgres database — using Kratix’s Promise-based framework. Promises are Kratix’s core abstraction for delivering “something as a service.” A promise defines an API, a set of workflows, and a destination (e.g., a Git repository or S3 bucket), allowing platform engineers to encode operational logic while providing a clean developer interface.

Abby emphasised that a Promise is not just about automating deployments, it’s about clearly defining what developers can ask for and under what conditions. This ensures internal platforms are built with policy, governance, and scale in mind.

Developer-Centric Platform APIs

Participants saw how Kratix turns Kubernetes Custom Resource Definitions (CRDs) into user-facing APIs. By offering a limited, carefully designed set of fields, such as name, environment, and team ID, platform teams can ensure their developers don’t get lost in a sea of Helm chart values or YAML complexity. The ability to compound Kratix Promises also allows platform builders to abstract away configuration options or provide default values for sub-Promises. This approach strikes a balance between developer autonomy and operational safety.

The Promise used in the workshop deployed a Postgres operator into a “worker” Kubernetes cluster, ensuring workloads could be cleanly separated from the platform’s control plane — a practice that improves scalability, security, and fault isolation.

From Database to Application

After deploying Postgres as a service, the workshop moved on to composition. Attendees created an “App as a Service” promise, a higher-order promise that depended on both Postgres and NGINX promises. This demonstrated Kratix’s composability: you can build richer platform experiences by stitching together smaller, independently defined services.

The App as a Service promise included a few parameters — application name, container image, whether a database was needed, and a port — and then wired up the underlying infrastructure behind the scenes. The end result: developers could request a full-stack app with a single Kubernetes resource.

Platform Engineering Theory: Re-Centralisation Done Right

While the hands-on experience was front and centre, Abby and Phill wove in critical platform engineering theory. They challenged attendees to rethink the post-DevOps world: while DevOps encourages decentralisation and team autonomy, platform engineering seeks to re-centralise, but only once bottlenecks are removed and self-service is implemented.

This “recentralisation” gives teams access to shared security, governance, and support services, without reverting to a ticket-driven, top-down IT approach. With Kratix, control resides in the platform, but the control remains with the developer.

GitOps, Portability, and Composability

A core tenet of Kratix’s model is GitOps. When a promise is executed, its workflows write declarative code to a Git repository or other state store, such as MinIO. This allows the actual deployment to be performed by Flux or ArgoCD, systems already trusted within most Kubernetes-based organisations.

Crucially, Kratix doesn’t need access to your clusters, networks, or clouds. It delegates deployment responsibility to your existing workflows, meaning it’s as compatible with mainframes and edge nodes as it is with Kubernetes.

Composition is another core benefit. Developers no longer need to request separate resources and manually connect them. Instead, higher-order promises manage the relationships and wiring between resources, removing fragility and streamlining the developer journey.

Portals, Promises, and Productisation

The final section of the workshop demonstrated how Kratix promises integrate with internal developer portals like Backstage. Rather than writing YAML files to define catalog entries manually, the team built a workflow that outputs Backstage-compatible YAML directly from a Kratix promise. These files were stored in MinIO, which Backstage was configured to read from.

This approach enables internal platforms to expose services in Backstage, CLI tools, or chatbots, all from the same Promise API. Abby pointed out that this eliminates the need to maintain parallel user interfaces, since Kratix’s model keeps business logic in the API layer, not scattered across UIs.

Attendees saw this firsthand when they deployed an application using a customised Backstage scaffolder that generated Kratix resource requests. The promise then handled everything: spinning up a database, deploying the app, wiring up the environment, and exposing it to users.

Real-World Use, Real-World Impact

Phill shared how the same Kratix-powered internal platform supported their hackathon across The Access Group, spanning engineering, professional services, and more. The system wasn’t just a toy: it supported real workloads, integrated with their own SSO and security layers, and enabled teams across functions to self-serve.

He also stressed that promises could be extended as needed. After releasing a Postgres promise, the first feedback was: “Can I get a different database?” And because promises are modular, Phill was able to deliver that quickly by reusing existing patterns and workflows.

Final Thoughts: From Hackathons to Scalable Platforms

Phill and Abby’s message was clear: Hackathons are the perfect proving ground for internal platforms. If your platform can enable developers to ship something real in a hackathon, it’s probably ready for production too.

Using Kratix, attendees saw how to define APIs as contracts, encapsulate operational logic in workflows, and deliver services through GitOps without sacrificing security or portability. They learned how to expose these services through a developer portal like Backstage, making their internal platform feel like a real product.

The takeaway? Working code — built in public, shared as patterns, and tested under pressure — is how you build platforms people love.