Shipping a Vibe-Coded App to Production: Infrastructure as Code, Backups and Maintenance
The top of the pyramid: how to actually ship a vibe-coded app to production with Infrastructure as Code, and keep it alive with backups, cron jobs and observability (Sentry, PostHog).
Gaetano Castaldo
The Top of the Pyramid: Going Live and Staying There
This is the last article in the From Vibe Coding to Production series. We are at the top of the pyramid, Levels 7 and 8, the ones that decide not only whether your app goes to production, but whether it stays there.
It is the part a founder or a junior developer knows least, and exactly for that reason it is where we see the most expensive mistakes: apps that are online but fragile, with no backups, with notifications that never fire and nobody noticing until it is too late.
Level 7: Infrastructure as Code - Environments Ready in Minutes
Sound familiar?
Setting up a new environment takes you days and in the end it only works on your machine? Your infrastructure is not code yet.
Today you can describe your entire infrastructure inside files and containers. That means a development environment you can spin up in minutes, not days.
The advantage is not only setup speed. With tools like Docker you can run tests on ephemeral databases or infrastructure, created and destroyed only during the test run. You speed up development and you speed up testing, two things that usually slow a hand-built project to a crawl.
It is a level that completely changes the quality and repeatability of what you ship. Having infrastructure as code means being able to recreate an identical environment at any time, on any machine. No more "it works only on my machine".
Level 8: Maintenance - Backups, Cron Jobs and Notifications That Work
Sound familiar?
If a wrong command wiped the database tonight, could you recover? If the answer is not "yes, from the last backup", you have a serious problem.
Maintenance is the last block of the pyramid, and it is almost always the one set up worst from the start.
The classic scenarios are familiar. There are no periodic backups, so a single error can wipe out months of data. You want notifications, but they never fire, because the queues that handle them were never set up. Trivial operations like clearing the server cache do not yet fit into well-defined protocols you can fully delegate to AI.
All of this rests on technical knowledge that is hard to hand off to an assistant: cron jobs, queue management, monitoring, automatic backups. It is work you do not see, until it is missing. And when it is missing, it usually goes missing at the worst possible moment.
Observability: Knowing What Happens in Production with Sentry and PostHog
Sound familiar?
Your app has grown but you do not really know what happens inside, or why some users vanish? You are missing observability: Sentry for errors, PostHog for behavior.
There is a part of running an application that almost no founder sets up, and it is exactly the one that lets you sleep at night: observability, the ability to know what happens in your app once it is live, without waiting for an angry customer to tell you. Here two tools answer two different, complementary questions.
Sentry monitors errors. When something breaks in production, it tells you exactly where and why: which point in the code, which sequence, which user triggered the exception. Instead of discovering bugs from one-star reviews, you see them and fix them before they spread.
PostHog gives you product analytics. It reconstructs the paths and clicks of users inside the platform, down to session recording, so you understand which interactions lead to a certain journey and where people get stuck or drop off. It is not just a marketing metric: it is proof of how the product is actually used, against how you thought it would be used.
Together they answer the two questions that matter once the app is online: "what broke?" (Sentry) and "what are users doing?" (PostHog). This, on top of backups and cron jobs, is what keeps an application under control over time.
A warning that ties this level back to Level 6 on compliance: recording sessions and events means touching real people's data. It must be configured with PII masking from the start, otherwise observability turns into a privacy problem.
Does Vibe Coding Replace the Developer?
Now that we are at the top of the pyramid, the answer is clear: in part yes, and that is exactly why the developer becomes more important, not less.
Much of writing code is now accelerated by AI, and that is a good thing. But all the knowledge of production and maintenance, the nine levels of this series, is simply not replaceable. It takes experience and continuous maintenance that is too often ignored.
The good news is that building a SaaS today is simpler, faster and more cost-efficient than a few years ago. The bad news is that the early ease hides everything that comes after. Before you say the work is done, make sure you have climbed all nine levels.
Let Us Take Your App to Production
If you have built an MVP in vibe coding and want to put it online in a solid way, that is exactly what we do at Castaldo Solutions: we take prototypes built by founders and bring them to production, secure, scalable and maintainable, step by step.
Talk to us about your app and we will take it to production without disasters.
Tags
Founder & CEO · Castaldo Solutions
Sono un consulente di trasformazione digitale con esperienza enterprise. Aiuto le PMI italiane ad adottare AI, CRM e architetture IT con risultati misurabili in 90 giorni.