The Last Mile: AI Writes Your App in 10 Minutes. Deploying It Takes 10 Hours.

It's a Tuesday afternoon. You open Cursor, describe a REST API you need — authentication, a few endpoints, a database layer — and by dinner it's working. You run it locally. The tests pass. You make a few tweaks, prompt your way through a couple of edge cases, and it's actually good. Production-quality, even.

Then you ask the natural next question: "How do I put this on the internet?"

And that's where the afternoon dies.

The Speed Asymmetry

AI has compressed the code-writing phase of software development faster than most of us have had time to absorb. Tasks that used to take a senior engineer a week now take an afternoon. That's not an exaggeration — it's the daily reality for anyone who's spent serious time with Cursor, Claude, or GitHub Copilot. The gap between "idea" and "working code" has collapsed.

The gap between "working code" and "running in production" has not.

Let's walk through what deploying a "simple" Node.js API actually involves when done properly. Not a toy project — something you'd actually put in front of users.

First, you need a Dockerfile. If you haven't written one before, congratulations: you've just discovered that containerization has its own learning curve. You need to pick a base image, understand layer caching, figure out why your node_modules aren't copying correctly, and decide whether to use a multi-stage build (you should). Budget two hours if you're learning, thirty minutes if you already know what you're doing.

Then, a container registry. Your image has to live somewhere. ECR, GCR, Docker Hub — pick one. Now figure out how to authenticate your CI pipeline to push to it. IAM roles if you're on AWS. Service accounts if you're on GCP. A token you'll definitely forget to rotate if you're on Docker Hub.

Speaking of IAM: if this is your first time setting up an AWS account for a real workload, you're in for a treat. IAM users, roles, and policies form one of the most powerful access control systems ever built, and also one of the most confusing. You'll read three Stack Overflow answers, apply a policy that's too permissive, narrow it down, break something, and eventually arrive at something that works and that you don't fully understand. This is normal. Everyone does this.

Load balancer. Your container runs somewhere. Traffic needs to reach it. That means a load balancer, which means a target group, which means a listener, which means security groups. Each one has its own configuration surface. Each one has a default that will silently bite you later.

SSL. You need HTTPS. That means a certificate. ACM makes this reasonably painless on AWS, but "reasonably painless" is doing a lot of work in that sentence. You still need to validate domain ownership, attach the cert to the right resource, and make sure HTTP redirects to HTTPS.

Health checks. AppRunner, ECS, and every other container platform needs to know your service is alive. That means an endpoint that returns 200. Which means configuring the health check path, the interval, the threshold, and waiting for your service to pass enough checks to be considered healthy before traffic is routed to it.

Environment variables. Your app needs secrets. Where do they live? AWS Secrets Manager? Parameter Store? A .env file you're definitely not committing to git? Each option has tradeoffs. Each option requires integration work.

Monitoring and logging. Your app is running. Something goes wrong. Where do you look? CloudWatch, if you're on AWS, which means configuring log groups, retention policies, and writing queries in a DSL that nobody enjoys. Or you add a third-party tool, which means instrumenting your code, managing another vendor, and paying for log storage twice.

DNS. Finally, you need a domain to point at your load balancer. Route 53, your registrar, propagation delays, and the peculiar joy of debugging why your CNAME isn't resolving yet.

That's the list. Every item on it is necessary. None of it is the thing you actually wanted to build.

The False Choices

Developers facing this wall have two realistic options today, and both of them are compromises.

Option one: raw cloud. AWS, GCP, Azure. You get full control, infinite configurability, and a learning curve that will consume weeks of your life. The documentation is comprehensive and mostly assumes you already know what you're doing. The pricing is granular and requires a spreadsheet to predict. The debugging, as we've written about before, involves archaeological work across log groups you didn't know existed. Raw cloud is genuinely powerful. It's also designed for teams with dedicated infrastructure engineers, and using it as a solo developer or small team means spending a significant fraction of your time on work that has nothing to do with your product.

Option two: managed platforms. Vercel, Render, Railway, Fly. Fast to start, friendly interfaces, sensible defaults. For a lot of projects these are the right choice and we're not going to pretend otherwise. But they have ceilings. Container support is limited or expensive. When your app needs auth at the infrastructure layer, you're still building that yourself. When something goes wrong, you're still tailing logs. When you need to scale beyond the happy path, you start hitting walls that weren't visible when you signed up. Pricing that looked reasonable at a hundred users looks different at ten thousand.

Neither option is wrong. They were both designed for a different era — one where the time to write the application was the long part, and the time to deploy it was the acceptable tax you paid at the end.

The AI Era Has Changed the Ratio

Here's the problem: AI tools have fundamentally changed what it feels like to be a developer, but only for one half of the job.

The Stack Overflow Developer Survey has consistently found that developers spend a large fraction of their working time on tasks outside of writing features — infrastructure configuration, environment setup, debugging tooling, dependency management. The number varies, but "more than you'd like" is always the honest answer. Before AI coding assistants, that felt tolerable because writing the features was also slow. The ratio of "time on actual product" to "time on everything else" was bad, but it was consistently bad.

Now the ratio is broken in a new way. Writing a feature takes an afternoon. Getting it to production still takes a week. The pain of infrastructure work hasn't decreased — it's just become more visible because the code that surrounds it got so much faster. The bottleneck has moved, and it's moved to deployment.

We've talked to a lot of developers building with AI tools who describe the same experience: the coding phase feels almost magical, and then you hit the deployment phase and it feels like you've stepped back ten years. The contrast is jarring. It's not that deploying got harder — it's that writing code got so much easier that the delta became impossible to ignore.

What Last-Mile Infrastructure Should Actually Look Like

We're not going to pretend we have a complete answer to this. But we can describe the properties that would actually solve it, because they follow pretty directly from the problem.

Zero Dockerfile required. If your project is a standard Node.js API or a Python service, the platform should figure that out and handle containerization automatically. Dockerfile expertise should be optional, not the entry fee.

Auth at the infrastructure layer. Managing user sessions, email verification, session tokens — this is table stakes for almost every app, and it's one of the most tedious things to build from scratch. It belongs in the platform, not in your application code.

Deployment in under five minutes from first push. Not after you've configured the pipeline, set up the registry, defined the task definition, and wired up the load balancer. Five minutes from git push to live URL, end to end.

Debugging that tells you what broke. Not a log group. Not a query. When a request fails, you should be able to click on it and see what happened. The correlation between a failing request and the logs it generated should be automatic, not something you reconstruct manually.

Pricing that reflects usage. Pay for what your application actually consumes, not for the number of seats on your team or for a tier that doesn't quite fit your workload.

None of this is technically impossible. It's just not what most infrastructure tools were designed to do, because most infrastructure tools were designed before AI made the code-writing part fast enough to make the deployment part the problem.

The Bottleneck Has Moved

The story of software development has always been about finding the next bottleneck. Compilers got fast, so we hit runtime performance. Runtime got fast, so we hit developer productivity. Developer productivity got faster with AI, so now we're hitting deployment.

Fixing the last mile isn't about building another Heroku. Heroku was designed for a world where developers were the bottleneck, and the goal was to give them more leverage. We're in a world now where AI is giving developers enormous leverage — but only up to the point where they have to ship. The next version of infrastructure needs to start from that assumption: code is fast, deployment shouldn't be the part that slows you down.

That's what we're building at Forte.