making things real

I believe infrastructure is the last bottleneck between ordinary people and extraordinary impact. And I think we're closer to removing it than most people realize.

Over the last couple of years, people who have never written a line of code started building software. They described what they wanted to an AI assistant and it just worked. A teacher builds an app to track reading progress for her students. Someone at a nonprofit builds an intake form that actually routes cases properly. A clinic coordinator builds a scheduling tool because the one they're paying $400 a month for doesn't do the one thing they actually need.

These people understand their problems with a clarity that professional developers rarely have. They've been living inside these workflows for years, and now they can finally build solutions that fit. The code isn't always pretty, but the thinking behind it is often better than what an outside engineer would produce, because they're not guessing their users' needs. They are the users.

But almost none of these apps reach the people they were built for. They work in a preview window on someone's laptop and they stay there, because the last mile of software — the part where you actually put it on the internet safely — still assumes you know what a Docker container is. It still assumes you understand TLS certificates and dependency vulnerabilities and environment variable management. Infrastructure knowledge is the bottleneck, and it has nothing to do with whether the app is good.

You paste a GitHub repo URL. Velveteen reads your codebase, figures out what framework you used, and generates the infrastructure files your project needs to actually run in production: a Dockerfile, environment variable documentation, coding standards based on your existing code patterns, and a proper .dockerignore so your image isn't full of junk.

Then it runs a security pipeline. Four industry-standard tools scan for leaked secrets, insecure code patterns, vulnerable dependencies, and generate a full software bill of materials. When the scanners find something, Velveteen doesn't hand you a JSON blob and wish you luck. It explains what's wrong in plain English, tells you why it matters, and gives you a prompt you can copy and paste right back into your coding AI to fix it. If everything clears, your app goes live at a URL you chose.

The security pipeline is the part I care about most. It would be easy to just deploy apps and skip the scanning, and it would be a much simpler product. But if someone is handling user data or collecting form submissions, they owe it to their users to do that safely, even if they don't know what "safely" means yet in a technical sense. So Velveteen does the checking for them and walks them through whatever needs fixing. The goal is to make security a normal part of shipping, not something you need a specialist for.

There's a children's book called The Velveteen Rabbit about a stuffed toy that desperately wants to become real. Eventually, through enough love and wear and belief, it does.

That's the situation with vibe-coded apps right now. Someone poured real thought and real care into building something. It works, it solves a problem, and the intent behind it is completely legitimate. But it's not real yet — not in the way that matters. It can't reach the people it was built for. It's sitting on someone's laptop like a stuffed rabbit on a shelf.

Velveteen is the process of making it real. Not by rewriting the code or passing judgment on how it was built, but by handling the infrastructure, security, and deployment so the thing can actually exist in the world and do what it was meant to do.

The people closest to a problem are the best equipped to solve it. That used to be an abstract principle because building software required years of specialized training. It's not abstract anymore. A social worker can build a case management tool in an afternoon. A teacher can build exactly the classroom app she's been wanting for a decade. These aren't toy projects. The thinking behind them is often sharper than what comes out of a product team three layers removed from the actual users.

What frustrates me is that infrastructure is still the thing standing between these people and the impact their work could have. Not talent. Not ideas. Not effort. Just the operational knowledge of how to get software from a laptop onto the internet in a way that's secure and reliable. And that knowledge gap is completely solvable. It shouldn't take a DevOps background to give your app a URL.

I keep thinking about what happens when you actually remove that bottleneck at scale. Not dozens of apps, but thousands. Built by people who know their domains inside and out, shipped without needing to hire an engineer or learn Kubernetes. The aggregate impact of that is something I find hard to overstate, and it's what gets me up in the morning to work on this.

Right now Velveteen works with public GitHub repos. You sign in with GitHub, pick a repo, choose a subdomain, and hit launch. The immediate next steps are private repo support, automatic redeployment when you push new commits, and the ability to commit the generated infrastructure files back to your repo as a pull request so they actually live with your code.

Longer term, I want Velveteen to be the obvious answer to the question that every vibe coder eventually asks: "OK, it works. Now what?" The "now what" shouldn't take a weekend and a consultant. It should take a few minutes, and the result should be something you're proud to share.

If you've built something and you're stuck at the "how do I get this live" part — this is what I'm building for you.