3. “Not Invented Here” in the Age of Vibe Coding
April 30, 2026
While working for Google, I figured that Google Cloud has some very useful services that I can use for my hobby projects. My favorite one was Cloud Run, which basically allows you to write your HTTP server using whatever language and stack you like, and then deploy it with just one command:
gcloud run deploy --source .
It actually needs some more parameters, but you get the idea.
Under the hood, the magic happens: your repository is git archive'd to a storage bucket, then Buildpacks determine what kind of technology you're using, Cloud Build builds your Docker image, a service revision is created and then you get a URL, something like https://you-service-name-some-random-letters.run.app, and when you hit this URL, your Docker container launches and your HTTP endpoint responds.
Cool, right?
I mean, yes, if we don't think of all the machinery that launches to serve your res.send("Hello World"). And sometimes we must think about it. Cloud Run will stop your container if it's unused for some time, and then the next visitor hits what is called a “cold start”: they wait while your container is starting, the serving process (node, python or whatever) launches, and so on. The cold start normally took 1 to 2 seconds for my tiny projects, but it could be worse.
Besides cold starts, there were some other things that were imperfect.
Deployment took 2-3 minutes: first of all, Docker layers were never actually cached, so even if you rebuild very soon, you still went through the full cycle; and on top of that, gcloud apparently used exponential backoff to wait for the build, which often added an extra half minute of waiting. No big deal, but.
Mapping your own domain to a Cloud Run service was easy, but took some time too. First, let Google know that you actually own the domain by verifying it using a DNS TXT record; takes a few minutes. Then, assign the domain to the Cloud Run service and wait for SSL certificates to generate, and this took up to an hour, sometimes more.
Finally, Cloud Run is essentially free when you have no traffic, but when you suddenly do, you start paying money. I never got beyond $1-$2 per month for any of the projects (which probably tells you something about their popularity), but for one project, a Durak card game, I started getting Cloud bills for $20 and more, which prompted me to do some emergency declouding, get a cheap VPS, and host it there. Yes, I spent some time configuring systemd and I lost an easy way to deploy updates, but at least I'm paying some fixed small amount, and the VPS will probably do well with 10x traffic increase before I start worrying.
But, whatever. All this aside, Cloud Run was the easiest way to have the code you just wrote deployed immediately, and I used it a lot. I had a bunch of Telegram bots sending me notifications about various things happening, some homemade analytics with some HTTP endpoints, and much more; I counted more than 30 deployed Cloud Run services scattered across maybe 20 GCP projects, and every few months I added more.
This needed to stop.
Maybe I'm old, but I'm opening the tutorial page for Caddy, or Dokku, or anything else, and I'm lost after 2 minutes. I remember the time when I could write a complete Apache VirtualHost definition without looking in the documentation, and this time is long gone; now I want one command to copy-paste. Maybe two. I don't want to figure out how to do what I want with a tool that has maybe a few hundred CLI flags and configuration options, call me lazy.
So I kept using Cloud Run, because it gave me that ability to deploy with one command, and I was unhappy, because I knew I would need to do something about my growing cloud footprint, but I could not figure out what to do.
Until I decided that enough is enough, and started vibe coding with Claude.
The decision to roll out my own solution instead of figuring out an existing one might be considered an example of what is called Not Invented Here. In its “See Also” section, that Wikipedia page helpfully links to articles like “Antipattern”, “Reinventing the wheel”, and “Wishful thinking”, giving you the idea that implementing crappy homemade solutions instead of reusing good full-featured third-party products is probably the bad one.
Well, well, well.
I came to Claude with a one-paragraph description of what I wanted: one server, Caddy to manage SSL certificates, each service in its own Docker container (I liked that part from Cloud Run), and a CLI command written in Golang to deploy a service. Claude gave me some initial README.md, which I then gave to Codex, and it added some more details, up to the shape of the CLI commands. By the way, I found that mixing different tools this way often gives better result: in this case, Codex raised some concerns Claude never mentioned.
Then Claude agents started implementing it, and after three 5-hour sessions I had a working solution that I happily used to deploy my first service on the VPS I purchased. Then another one, and another. After several evenings, I'm almost done with Cloud Run. I wouldn't have believed if anyone had told me that a week ago.
And now I have a few more things to say.
I don't want to learn your tool. I don't want to sign up for your SaaS or PaaS or whatever-as-a-service. I would rather spend the same amount of time, or less time, to implement my own thing, which will cover the exact use cases I need, the way I need it, and won't bother covering the use cases I don't care about.
Is it always worth rolling out your own thing? Not at all. After all, I used Caddy (without writing a single line of its configuration), because issuing SSL certificates is something I would rather ask someone else to do. But for anything else, vibe coding a small tool that does the job sounds like a great option to me.
Of course, and I wrote about it already, I fully realize no one cares about my tool, and no one except me will ever use it. Code is cheap now, and tools are cheap too. I don't want to use your tool, you don't want to use mine.
Having said that, if you think you want my tool, here it is: decloud
Now, if you are a hobby developer or a small startup considering deploying your code to the cloud, you might want to stop and think a little bit. What were the main reasons of going to the cloud? First, it was fast, and second, it was obvious that reimplementing cloud services at home is just unreasonable. But you don't need to reimplement all cloud services, only a few of them, and you can probably vibe-code those few and then use them for free, and you will probably save on the learning curve of cloud services too. And you don't need to deal with IAM, which is the single worst nightmare in every cloud service I worked with.
And, of course, rolling out your own thing is just much more fun than using someone else's. Even if you haven't written a single line of code in it, because, you know, Claude. Still fun.
I'm going to keep “Inventing Here”.