Vibe Coding vs. Production Reality

You built a prototype in a weekend with Claude. Not a toy — something real. A Stripe integration, a user signup flow, a dashboard that queries an external API and renders the data in a table. It took you maybe twelve hours spread across Saturday and Sunday. You prompted your way through the parts you didn't know, copy-pasted the generated code, tweaked a few things, and it worked.

A friend tries it. It works. You post it on Indie Hackers with a "Show HN"-style writeup, get 200 upvotes, and 50 people sign up in the first hour.

Then the pain starts.

Response times climb from 200ms to 8 seconds. Your free-tier database starts rejecting connections. Someone DMs you saying they logged in and saw another user's data — actually saw it, with their name and email address in the header. And then a message from someone you've never heard of: "Hey, quick heads up — I found your API key in a public GitHub commit."

This is not a hypothetical. Some version of this story plays out hundreds of times a month.

This Is How Real Breaches Happen

The failures that end products are rarely sophisticated. In July 2025, Tea — a safety app for women that had just hit #1 on the App Store — was found to have left a cloud storage bucket open to the public internet. About 72,000 images leaked, including roughly 13,000 verification selfies and government IDs. Days later, a second exposure surfaced more than a million private messages. Nobody broke encryption. Someone found a URL that should not have been public, and a script downloaded everything behind it.

And this failure mode is older than AI coding tools. Securitas — a security company — left 3TB of airport employee records, including ID-card photos and national ID numbers, in a misconfigured storage bucket. A Verizon vendor exposed millions of customer accounts the same way, account PINs included. Companies with security teams and compliance budgets keep showing up in these headlines for the same reason: the major clouds expose hundreds of settings, plenty of combinations are quietly unsafe, and the mistake costs nothing until someone hostile finds it.

If teams with dedicated security staff get this wrong, a solo founder shipping AI-generated code over a weekend should not expect to do better. The realistic fix is infrastructure where the dangerous configuration doesn't exist.

That's the design principle behind Forte. There is no storage setting that makes your users' files public. Every endpoint sits behind a managed gateway. Sign-in, sessions, and password storage are handled by the platform — your application never holds a password, so no bug in your code can leak one.

What "Vibe Coding" Actually Produces

To be clear: AI coding tools are impressive. A Claude-generated Express app handles the happy path well. The route handlers are clean, the schema validation is reasonable, the Stripe webhook integration works on the first try. For getting from zero to a working demo, nothing is faster.

But a vibe-coded app is missing a specific set of things. The AI isn't wrong to omit them — they don't matter while you're testing alone on your laptop. They start mattering when real users arrive, and they tend to matter all at once.

No rate limiting. Your API accepts requests as fast as clients send them. That's fine with one user on localhost. It is not fine when someone's automation script hits your /api/generate endpoint 3,000 times in a minute. On Forte, every endpoint sits behind a gateway with DDoS protection and bot detection, so abusive traffic is dropped before it reaches your code or your bill.

Sessions stored in memory. The most common scaffolded auth setup keeps session state in the server process. Restart the server and everyone is logged out. Run two instances and lookups fail half the time — or return the wrong user's session, which is exactly how "I saw someone else's data" happens. Forte issues and stores sessions at the platform level; they survive restarts, deploys, and scaling without you building a session store.

No recovery at the infrastructure layer. An unhandled exception kills the process, and nobody notices until a user reports it. Forte restarts crashed services, rolls back failed deploys, and adds capacity when traffic spikes — without an on-call rotation watching for it.

Secrets in your git history. The .env file holding your Stripe key and database credentials has been committed at least once, and git history is forever. On Forte, configuration is injected at runtime and never lives in your repo — and payments don't require you to handle a payment-provider key at all, because they're built into the platform.

Auth bolted on, not designed in. Session middleware added to the top of app.js after the routes were written protects whichever routes it happens to cover. One router.get('/admin/users', handler) registered before the middleware is an unauthenticated endpoint in production. Forte checks authentication at the gateway, in front of your code, with the protected surface declared in one place instead of scattered across middleware ordering.

Logging is console.log. When production breaks, you have whatever happened to land in stdout, and if the process restarted, you have nothing. Forte records every request and keeps the log lines written while handling it, so the trail exists before you know you need it.

None of this is a critique of the developer or the model. It's infrastructure, and the real question is whether you assemble it yourself or start on a platform that ships it as the default.

The Deployment Cliff

At some point you decide to do this properly. Not a free tier — something that can handle growth.

This is where you discover the deployment cliff.

You go to containerize your app and realize you have no idea what a Dockerfile looks like for a Node.js app with a native dependency. You find a template, copy it in, and the build fails because your app assumes a specific Node version. You fix that, the container builds, and it won't start because process.env.DATABASE_URL is undefined — the .env file you were relying on isn't in the image. You set the variables by hand in a dashboard. Now the health check fails: it's probing port 80 and your app listens on 3000. Meanwhile, you're being billed for a container that has never served a request.

Then comes the pipeline. Deploying by hand worked once; now every fix means build, tag, push, deploy, and you start writing CI YAML to automate it — a new language with its own debugging cycle, where every mistake costs a 10-minute build to discover.

And after all of it, your service still scales to zero on the cheap tiers, so the first user after a quiet period waits 8 seconds for your stack to spin up.

The deployment cliff isn't one problem. It's ten problems that arrive together, each blocking the next, none of them visible until you're in the middle of them.

Forte removes this layer outright. Connect the repo and Forte inspects your code, figures out how to containerize it — any framework, no Dockerfile, no build config — and deploys it with the port detection and health checks already handled. After that, every push to your branch (or every release, if that's how you ship) builds and deploys automatically. There is no YAML because there is nothing to configure, and services stay warm, so there are no cold starts to apologize for.

The Options When You Hit the Cliff

When this all lands on you at once, you have four options. They're worth being honest about.

Patch the existing stack. Add a Redis session store, rate-limiting middleware, a Sentry SDK, a health check endpoint, a secrets manager integration. Each fix is reasonable in isolation. Together they're five configuration surfaces and four vendor dashboards that were never designed to work together, and a deployment process that breaks whenever you touch it.

Learn AWS from scratch. The right long-term answer for anyone who wants infrastructure as a career skill — and a 3-to-6-month detour before you're competent enough to avoid expensive mistakes. If you're trying to validate a product, you don't have six months for this.

Buy the pieces separately. Auth0 for authentication, Datadog for observability, Railway or Render for hosting, Sentry for errors. A legitimate stack, at $300–500 a month before your first paying customer, each piece with its own SDK, its own billing cycle, and its own failure mode.

Move to a platform that owns the production layer. Sessions, auth, deployment, scaling, payments, request logs — as defaults rather than integrations. This is what Forte is built to be. You connect the repo you already have; the app doesn't change, and the layer underneath it becomes someone else's job.

What Production-Ready Actually Means

"Production-ready" gets used loosely. It's actually concrete:

Sessions that survive infrastructure. Stored outside the process, valid across restarts, deploys, and multiple instances, and revocable when you need them gone.

Auth enforced in front of the application. Token validation at the gateway, before requests reach your code, so a forgotten middleware line isn't a public endpoint.

Containers that recover. Crashes restart, failed deploys roll back, traffic spikes add capacity — automatically, because nobody is watching at 3 AM.

Logs that answer questions. Request IDs, timestamps, user context, and the ability to pull up every log line for one specific request instead of keyword-searching and hoping.

Secrets that never touch the repo. Injected at runtime, managed in one place, absent from your git history.

Deploys without ceremony. Push to a branch or cut a release; the build, the deploy, and the rollback path all happen without a manual step.

On Forte, this list is the starting state — with user sign-in and Stripe-powered payments on the same platform for the day you start charging.

The Gap Is Infrastructure

The gap between "I built a thing" and "I run a product" is almost entirely infrastructure. AI tools have changed how fast you can build; they haven't changed what it takes to run. The code is rarely the hard part anymore. The layer underneath it — deployment, sessions, secrets, observability, scaling — still is.

If your vibe-coded app has real users and you're starting to feel the cliff, the move isn't a rewrite. Connect the repo to Forte: containerization, CI/CD, auth, payments, and per-request debugging are already wired, and the 8-second cold starts, session leaks, and missing rate limits stop being your problems to solve.

Start building free →