Building an Internal Developer Platform from Scratch: Lessons from InfraFlow

Why I Built an Internal Developer Platform

Most student portfolio projects are CRUD apps with a nice UI. I wanted InfraFlow to be something different — a project that forced me to think like a platform engineer, not just an application developer. The goal was simple to state and hard to build: give a developer everything they need to design, deploy, and observe a workflow, without leaving one platform.

That's what InfraFlow became — an Internal Developer Platform (IDP) built around a five-stage pipeline: Design → Execute → Deploy → Observe → Recover.

The Five-Stage Pipeline

Breaking the platform into distinct stages was the single most important design decision I made. It gave every feature a clear home and made the system easier to reason about as it grew.

Design — A visual workflow studio where users construct workflows as connected steps, rather than writing raw YAML or config files by hand. Lowering that barrier matters more than it sounds like it should; the fastest way to kill developer adoption is to hand them another DSL to learn.

Execute — Workflows are modeled as DAGs (directed acyclic graphs) for task scheduling. This let me express dependencies between steps cleanly — step C only runs after A and B complete — and gave the scheduler a structure it could reason about instead of a flat, ordered list.

Deploy — Deployment is handled through GitOps, using ArgoCD to keep the cluster state in sync with what's declared in Git. This was one of the more eye-opening parts of the project: once Git becomes the source of truth, "what's actually running in production" stops being a question you have to guess at.

Observe — A full observability stack — Prometheus for metrics, Grafana for dashboards, and Loki for logs — gives visibility into what workflows are doing in real time, not just whether they succeeded or failed.

Recover — The stage most tutorials skip. Things fail. A platform that only handles the happy path isn't a platform, it's a demo. Building recovery paths in from the start meant thinking about retries, failure states, and rollback as first-class design concerns, not an afterthought bolted on later.

What Kubernetes Actually Taught Me

Before InfraFlow, Kubernetes was a word I recognized from job postings. Building an IDP on top of it forced me to actually understand why each piece exists — why you'd reach for a StatefulSet over a Deployment, why namespaces matter for isolating workflow environments, why resource requests and limits aren't optional details you can skip.

The GitOps layer with ArgoCD changed how I think about deployment entirely. Instead of deployment being an action someone takes, it becomes a state the cluster continuously reconciles toward. That shift — from "I deployed the app" to "the cluster is converging on what Git says it should be" — is the kind of thing that's hard to appreciate until you've built the reconciliation loop yourself.

Why Observability Isn't Optional

I used to think of monitoring as something you add once things are "done." Building the Observe stage of InfraFlow changed that. Once workflows can fail in a dozen different ways, dashboards and logs stop being nice-to-haves — they're the only way you actually know what's happening inside a system you didn't watch run.

Wiring Prometheus, Grafana, and Loki together also taught me that observability is its own design problem. What metrics actually matter? What should trigger an alert versus just show up on a dashboard? Getting this wrong means either missing real issues or drowning in noise — and I got it wrong more than once before it felt right.

Working as a Team on Infrastructure

InfraFlow wasn't a solo project — it was built and documented with collaborators as part of a formal academic project report, supervised faculty included. Infrastructure work has a different collaboration rhythm than application code: you're not just reviewing pull requests, you're aligning on architecture decisions that are expensive to reverse once workflows depend on them. That made early design conversations matter more than they typically do in a standard web app.

What I'd Do Differently

If I started InfraFlow again, I'd invest earlier in the Recover stage instead of treating it as the last piece to build. Failure handling has a way of revealing design flaws in the other four stages — the earlier you're forced to think about what happens when something breaks, the better the rest of the system ends up being.

Closing Thoughts

Building InfraFlow taught me more about real infrastructure than any single course or tutorial could have. It's one thing to know what Kubernetes, GitOps, and observability tooling are. It's another to design a platform where all of them have to work together, under real failure conditions, for a workflow a developer actually wants to build.

That gap — between knowing the tools and building something real with them — is exactly what I was chasing with this project.