Overview

Where this came from. Notes from a platform engineer who saw a gap.

Claude and I set out to learn some new tech in spare time. We accidentally built an IDP for vibe-coded apps. Naturally, the IDP itself is vibe-coded.

V2C stands for Vibe to Cloud, in case that wasn't obvious. I'm sure I could have come up with a better name.

My background is on-prem infrastructure. Hyperconverged platforms, servers, storage, VMs, hypervisors, vendor support contracts. I pivoted to platform engineering a while back. My day job since has been cloud and IaC, whilst still keeping the on-prem lights on. I'm a platform engineering team leader focused on the underlying foundation, and I've spent the last year picking up Kubernetes certs so that's where my mind's been.

Across platform engineering as a discipline, the work most teams are focused on right now is building the IDP for software developers. Sensible, and it's delivering real value to developers. The thing that started bothering me was the gap on the other side. Software engineers will get an IDP. Analysts, PMs, operators, finance people, marketers, anyone using an LLM to write code aren't going to. The new ‘whole business’ audience probably needs an IDP even more than a traditional dev does.

Where this came from

I started V2C as a fun side project, in spare time, on a personal Azure subscription. The honest first goal was learning. I wanted hands-on time with APIM, Spacelift, Snowflake and Entra in a lab environment where I could break things without consequence. I got that, in much greater depth than I expected. The thing that came out of the learning is, at this point, a working platform. I'm still surprised by that.

The bigger reason I kept going is one I think a lot of platform people will recognise. Moving from on-prem to public cloud felt risky and expensive at first. I made my peace with it. Now there's another step landing: vibe-coded apps querying enterprise data, in someone else's cloud, with credentials nobody quite knows where they came from. Public cloud was a step I was prepared to defend. Vibe-coded apps accessing business data without governance feels like a step too far. I hope that resonates with people in similar seats.

Why I'm the one writing this, and how

I have a computer science degree. I haven't written code in anger for years. My day-to-day is platforms: how they fit together, what they cost, where the controls have to live, what makes a deploy story work in a regulated environment, what makes one fall over. The expertise I bring to V2C is knowledge of the pain a platform team feels and a fairly specific mental model of how an enterprise web app should be put together. The expertise I do not bring is fluency in writing the actual TypeScript and SQL and HCL that make any of it run.

What changed is Claude Code. The version of V2C that exists is the result of a partnership: I bring the platform knowledge, the architecture decisions, the “no, that won't fly with InfoSec” veto, the integration choices, the trade-offs. Claude Code writes most of the code. We argue about design. I push back when something feels wrong. It pushes back when I'm about to do something stupid. The Snowflake integration in particular, where the same generic 390186 error meant five different things on five different days, would have taken me months to chase down on my own. The two of us got through it in days, with Claude Code reading log lines I couldn't parse and proposing the integration-config changes that, taken together, actually fixed it.

That's the honest story of how V2C got built. A platform engineer who knows what good looks like at the architecture level, paired with an LLM that can hold the whole codebase in its head and write the lines I haven't typed in years. Vibe-coded our way to something I wouldn't have got near alone. There's a separate post later in this series about what that pairing has cost me in Claude tokens. Short version: a lot, and there's a reason I no longer open the Barclays app on my phone. Worth it. The technical depth in the rest of these posts is real. The “I” in those posts is, more often than not, a “we.”

The actual problem

A business user has an idea for a small internal tool. The honest path to getting it built used to involve a service-management ticket, a six-week wait, a vendor procurement, or an engineering rotation. Now it involves a chat window. The tool gets built in an afternoon and ends up running as a Python script on someone's laptop with a database password copy-pasted out of a wiki.

That's not the user's fault. They asked the obvious question (how do I make this thing work?) and the obvious answer worked (paste the credential and run it). The expensive part of regulated software (identity, secrets, audit, isolation, lifecycle) was never offered to them as a path of least resistance. So they took the path that was.

What the existing tools do and don't solve

There's a category of vibe-coding and low-code-deployment tools that's been growing fast. Each is good at a different slice. None of the ones I've looked at land the app inside the customer's existing cloud, against the customer's existing data, under the customer's existing identity provider, with credentials that never enter the container. That combination is the actual ask in any serious enterprise. Everything else is a workaround.

The category I keep wanting to point at is “deployment platform that lands inside our perimeter and integrates with our stack.” That category is mostly empty. V2C is one attempt to fill it.

What V2C is

Mechanically, V2C is a control plane that lives in your cloud, holds the credentials your existing services already trust, and provisions per-app infrastructure when a developer (or their coding agent) pushes a repo. Per-app namespace in AKS. Per-app User-Assigned Managed Identity, federated to the namespace ServiceAccount via the cluster's OIDC issuer. Per-app Snowflake user mapped to the MI's object ID. Per-app APIM subscription so AI calls go through your enterprise contracts. Per-app Entra app registration if the app needs SSO. Per-app Spacelift stack so the IaC story is intact.

Every one of those is provisioned automatically. Every one of those is torn down when the app is deleted. The platform engineer who would have been writing those resources by hand for the fortieth time gets that Tuesday back.

Why the integrations matter more than the surface

It would be easy to look at V2C and see a deployment portal. The deployment portal is the visible bit. Most of the value is hidden behind it.

Per-app federated identity to Snowflake means the audit log shows exactly which app accessed which view at which timestamp, instead of a shared service account doing everything. Per-app APIM subscriptions mean usage attribution by application without any custom telemetry. Per-app Entra registrations mean SSO on the analyst's tool comes for free. Per-app Spacelift stacks mean the infra story is reviewable in a way the auditors actually want.

None of those are interesting in isolation. All of them together mean the same review cycle that used to take six weeks for one app now covers every future app the platform produces. That's the multiplier. It's also the bit you can't buy off the shelf, because the integrations have to fit a specific stack and the controls have to read like the controls the customer already has.

The shape of these posts

What follows is a series of longer posts on the parts of V2C I learned the most building. The four I'd call the deepest are the Snowflake one (the longest, because that's where the worst pain was and where the platform's most-asked-about capability lives), the approval-flow one (the loop most platforms either hand-wave or skip), the AGENTS.md one (the bit that turns governed data into something a non-developer can actually use), and the APIM one (the most candid of the lot, because the AI access architecture has a deliberate compromise in it that I'd rather explain than hide).

The rest are shorter pieces on the supporting cast: Entra SSO via an oauth2-proxy sidecar, the maintenance loop that patches base images when nobody's redeploying, the Spacelift integration, the pods/logs/restart panel that takes platform engineering off the critical path for “please restart my pod,” the two onboarding paths and the small UX change that took the friction out of the second one, and an honest note on building all of this without a budget.

I started this because the gap kept bothering me and nobody else seemed to be filling it in a way that would survive an enterprise security review. The integrations turned out harder than I expected. I ended up with a side project that does more than I planned for, and I'm honestly not sure what to do with that yet.

Who this is for

These posts assume you've hit at least one of the same walls. You know what External OAuth is. You've sworn at AAD app role assignments. You have an opinion about whether a per-project Managed Identity is a good idea. If you're evaluating any of the off-the-shelf low-code or vibe-coding deployment tools for an internal AI-app problem and they don't quite reach into your perimeter, this is the kind of thing you'd build to close the gap. I built it. Here's what worked.

If you're interested in seeing what I've created in action, there's a demo video below.