Building the Data Platform's Front Door

A data platform is only as good as the number of people who actually use it. We had the pieces (a catalog, data products, a query engine) but they were scattered across tools, and most of the company didn't know where to start. So I built a front door: one internal site that ties it together.

It also happens to be where I got my web-dev reps, which is why this very portfolio exists.

What it does

The portal is a Next.js app behind company SSO. The useful bits:

• A data-product catalog you can browse and filter, linked through to the governance catalog for the full detail.
• Docs: how to connect, how to run a query, who owns what.
• An API page where you can pull a sample from a data product through the lakehouse without leaving the browser, so people can see the thing work before they wire anything up.
• News and guild posts for platform updates, plus self-hosted usage analytics so we could see what people actually opened.

Shipping it end to end

The interesting part for me was owning the whole path, not just the React. I set up the project on our infra portal, wrote the Dockerfile and CI, and deployed it to Kubernetes. I wired up SSO with the identity team, moved secrets out of the repo and into the deploy pipeline, and worked through the networking so an internally hosted site could be reached the way people expected.

None of that is the flashy part of a frontend, but it's the part that decides whether the thing stays up and whether anyone trusts it with their login.

Why a front door matters

Internal platforms tend to die quietly. Not because they don't work, but because nobody can find them, nobody knows what changed, and the first five minutes are confusing. A front door fixes the cheap version of that problem: discovery, docs, and a query you can run in the browser. It made the platform legible, which is most of what adoption needs early on.

The other thing it did was teach me full-stack delivery on top of the data work: design, build, containerize, deploy, secure, and keep it running. That mix is exactly what I reach for now when a platform needs a usable surface, not just an API.