AI Made Building Apps Easy, but Who Really Runs Them?

A few months ago, a product manager at an agency reached out to us. They had built a client reporting app over a weekend using an AI coding tool and made it live so customers could try it. It worked great until we found that authentication was broken and the app’s admin interface was accessible to anyone who could discover it. Nobody was on call, and nobody had patched anything since the day it launched.

That story is no longer unusual. We are increasingly seeing non-engineers build applications in hours to test their ideas, then push them to production without much thought for security, scaling or performance. More often than not, an AI-coded app is built for speed and functionality, and its creator hasn’t had the time, or the background, to make sure it’s robust, secure and performant. We often see these apps running fully open on public infrastructure.

The builders aren’t careless. The tools simply make it so easy to get to “it works” that nobody stops to ask what happens next.

This isn’t an exaggeration. Stack Overflow found 84% of respondents use or plan to use AI tools. Gartner predicts that by 2028, 40% of new enterprise production software will be created with vibe coding techniques and tools. What almost nobody is talking about is what happens the moment that app needs to survive contact with real users.

The People Deploying Apps Have Changed. The Infrastructure Hasn’t.

Most infrastructure was designed around the assumption that whoever deploys an app understands what they’re deploying it onto. Now, more production apps are being shipped by product managers, founders and domain experts who prompted their way to working software.

While they are capable builders, they are not—and don’t need to be—infrastructure experts. But their apps still need uptime, patching and a plan for when a traffic spike occurs. Gartner forecasts that prompt-to-app approaches adopted by citizen developers will increase software defects by 2,500% by 2028.

The result is a widening gap between how fast something can be built and how ready the infrastructure underneath is.

The Old Tradeoff Doesn’t Work Anymore

Teams shipping AI-built apps today are often stuck with options that weren’t designed to keep up with vibe-coding speeds.

Serverless platforms are an easy entry point. The trouble can start when unpredictable traffic arrives, such as a launch post that takes off or bots hitting an unauthenticated endpoint. The usage-based pricing model can make costs difficult to predict under these traffic patterns. What initially looked affordable in a demo can become expensive in production, and scaling may require changes to accommodate platform constraints instead of the app’s actual needs.

A self-managed VPS flips the tradeoff. Cost stays predictable, but now someone is on the hook for ongoing admin work, including patching, monitoring, scaling and security, that assumes a level of operational capacity. Most solo builders and small teams simply don’t have the resources for this, so patches begin to slip, and nobody notices until an outage or breach.

The infrastructure industry has spent years watching costly, hard-to-predict failures come from this kind of mismatch between who’s operating a system and what operating it requires.

What “Middle Ground” Infrastructure Requires

This shift is taking developers into a new era. It’s become clear that a managed layer built for this moment can’t just split the difference between serverless and VPS. The next layer of infrastructure has to be tested against these four questions:

Is cost predictable under a spike? A successful launch shouldn’t produce a surprise invoice. Ask what happens to the bill at ten times the normal traffic. Bandwidth and egress, database reads, function invocations and log storage are often billed separately, and they can add up faster than the headline price suggests.

Can it run safely without a dedicated ops hire? Consider who applies OS and runtime security patches, and how quickly. Check that backups run automatically and that restores work, since an untested backup is a guess. Confirm alerts go somewhere a human will see them. If the answer to any of these is “the customer,” assume it’s work that will get skipped.

Can the app grow without a complete rebuild? Growth from 100 to 100,000 users shouldn’t automatically require a complete rebuild. Assess where each layer hits a ceiling. Watch for platform-specific constraints the app gets built around, like proprietary runtimes, execution time limits or custom storage APIs.

Are the security defaults sensible? Given the security risks in AI-generated code, infrastructure security is an important layer of defense, though it cannot fix vulnerabilities in an application’s authentication logic. Ask whether databases are private by default or reachable from the Internet. Look for basic protection against bot traffic and role-based access, so one leaked credential doesn’t expose everything.

Many platforms today are built to do one or two of these well. That was a reasonable tradeoff when the person choosing the platform understood infrastructure well enough to accept it, but it is now riskier when that base level of expertise isn’t there.

The Infrastructure Layer Hasn’t Caught Up

Practitioners don’t need to wait for the market to catch up. The most effective move is to make the safer path easier to follow. AI changed who builds software much faster than the industry changed how that software runs. This isn’t fully priced in yet. While the tools are radically more accessible, the infrastructure behind them hasn’t moved at the same speed. Closing that gap is the next real infrastructure problem, and the teams that solve it first will spend far less time cleaning up after the apps AI helped build.