The Last Mile of Software

You can build a working app in an afternoon now. Getting it into the hands of the people who need it can still take a weekend, a credit card, and a vocabulary you never asked to learn.

That gap has a name. It is the last mile of software, and it is where most AI-built work quietly stops.

What is the last mile of software?

The last mile of software is everything between “it works on my screen” and “people use it every day.” It is the home the app runs in, the address people open, the data that survives a refresh, the decision about who can see it, and the upkeep that keeps it alive next month.

The phrase comes from telecoms and delivery, where the final stretch to the front door is the slowest and most expensive part of the trip. Software has the same shape. The factory got fast. The road to the door did not.

AI made the first mile almost free

Writing code used to be the expensive part. It is not anymore.

At Google, three quarters of all new code is now generated by AI and approved by engineers, according to Sundar Pichai in April 2026, up from half the autumn before. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools in their work.

And it is not only developers. A product manager describes a dashboard to Claude and gets one. A shop owner asks ChatGPT for a booking page and gets one. A teacher builds a quiz game for Monday’s class on a Sunday night. The tools are good, they are cheap, and they are getting better every month. (For a closer look at what people are actually making, see what people are building with AI in 2026.)

So the first mile, from idea to working thing, has collapsed from weeks to minutes.

Why the last mile did not move

Here is the strange part. In that same Stack Overflow survey, about three in four developers said they do not plan to use AI for deployment and monitoring. The thing AI is best at is writing the code. The thing that comes after is still done by hand, in dashboards, by people who know which buttons to press.

Google’s 2025 DORA report, one of the largest studies of how software teams deliver, found that AI adoption still has a negative relationship with delivery stability. More code is arriving faster at a road that was not built for the traffic.

Andrej Karpathy, the researcher who coined “vibe coding”, wrote up building a small menu app with AI in 2025. The local version came together quickly. Making it real took most of the effort, spent clicking through settings pages for keys, sign-in and hosting. At the point it felt 80% done, it was, in Karpathy’s words, “closer to 20%.” We tell that story in full in Outgrowing the App Builder.

If someone who helped build modern AI finds the last mile hard, the rest of us are not doing anything wrong.

Where does the time actually go?

Even for professional developers, writing code was never most of the job. Atlassian’s State of Developer Experience research found that developers spend only about 16% of their time actually coding, and that half of them lose ten or more hours a week to friction around it. AI is shrinking the 16%. The rest is still there.

For people who build with AI and are not developers, the balance is even more lopsided. The app takes an evening. Then come the questions with no obvious answers: which host, which database, what a DNS record is, why the page that worked yesterday shows an error today.

The demand is not small. When Bolt users started publishing what they made, Netlify reported that more than a million AI-generated sites went live on its network in five months. That is a million people who reached the last mile in one season, and those were mostly simple sites. The apps with data, sign-in and schedules are the ones that stall.

What sits between “it works” and “people use it”?

Picture a sales lead who asks an AI tool for a dashboard that shows how the quarter is going. Twenty minutes later it exists. It looks great. It lives in a chat window, or in a folder on one laptop.

For the team to actually use it, it needs:

• A home. Somewhere it runs when the laptop is closed, at an address that does not change.
• Data that stays. Numbers that are still there tomorrow, not reset on every refresh.
• Access. Only the sales team should see it. Maybe the CFO too. Nobody outside the company.
• Secrets kept secret. The key to the CRM cannot sit in the code or in a chat history.
• Updates that do not break things. When the lead asks for a new chart, the link everyone bookmarked should keep working.
• A way to see what went wrong. Logs, and a way back to yesterday’s version.
• An owner. Someone it belongs to, so it does not become an orphan when they change jobs.

None of this is the dashboard. All of it decides whether the dashboard matters.

Why today’s options only solve part of it

There are excellent tools for every piece of this. The problem is who they were built for.

Developer platforms

Vercel, Netlify and Render are very good at what they do. They were designed for developers and engineering teams who work in Git, think in build pipelines, and know what an environment variable is. If that is you, they are a fine choice. If you have never opened a terminal, the first screen asks questions you cannot answer yet. We are honest about where the line sits in our comparisons with Vercel, Netlify and Render.

Prompt-to-app builders

Lovable, Bolt, Replit, v0 and Base44 made the first mile magical, and several of them do give you a live URL and a backend. The trade is that the home lives inside one builder. Your app, its data and its hosting are tied to the tool you happened to start in, and to its pricing. When you outgrow the builder, or want to build somewhere else, the home does not come with you. See how we compare with Lovable.

The raw cloud

AWS, Google Cloud and Azure can do everything. That is the problem. To use them well you have to become, at least part-time, the DevOps engineer you were trying not to need.

Put those three side by side and a gap appears. Nobody designed the last mile for the person who builds with AI and does not want a second job.

What would a last mile built for AI builders look like?

If you started from the builder rather than from the infrastructure, a few principles fall out:

1. Say what it needs, not how to build it. “This needs a database and only my team can see it” should be enough.
2. Any tool in. Whatever you made it with today, and whatever you switch to next year.
3. Everything included. Data, storage, AI models and sign-in come with the home, without five accounts and five bills.
4. One link that lasts. Every update lands at the same address.
5. Private by default, shareable on purpose. You decide who sees it, and you can change your mind.
6. Nothing hidden underneath that you cannot leave. Your code and your data stay yours.

How CloudGrid closes the last mile

This is the problem CloudGrid exists to solve. You keep making things with the AI tool you already use, Claude, ChatGPT, Cursor, Claude Code, Codex, Gemini or Antigravity. When it is ready, you tell that tool to plug it in. The Grid assembles what the creation needs around it: a runtime, a database, storage, AI models without API keys, identity and access, and a stable address. Then it is live.

There is no repo to set up, no Docker, no cloud account. Updates keep the same link, every version is kept so you can roll back, and you choose whether it is private, shared with your team, or public. How the Grid works, in five minutes walks through it, and the Grid shows what surrounds every creation once it is live.

The last mile does not have to be a weekend. It can be one sentence.

Key takeaways

• The last mile of software is everything between a working app and an app people use every day: a home, data, access, secrets, updates and an owner.
• AI collapsed the first mile. Code is now cheap, but the work after the code has barely changed.
• Today’s options each solve part of it for a specific audience: developer platforms for engineers, app builders inside their own walls, the cloud for people willing to run it.
• A last mile for AI builders starts from intent, works with any tool, includes the essentials, and keeps one link through every change.

If you run a team where everyone is suddenly building, the same gap shows up at company scale. That is the subject of The Cloud Wasn’t Built for This.