The Cloud Wasn't Built for This

Cloud platforms were designed around one assumption: a small group of engineers ships a product. That assumption broke the day the finance team built its own forecasting tool.

Inside most companies, software is no longer made only by the people whose job title says so. This post is about what that does to the cloud, and what hosting internal tools built with AI actually requires.

Who builds internal software now?

Increasingly, everyone. Gartner predicted back in 2022 that by 2026, at least 80% of the people using low-code tools would sit outside formal IT. AI coding tools have pushed that much further than drag-and-drop ever did.

The surveys from this year agree. In Retool’s 2026 build-vs-buy report, 60% of builders said they had built something outside IT’s oversight in the past year, and the most common things they built that way were internal tools, automated workflows and dashboards. In its 2025 builder report, only 35% of the people building were engineers. Retool sells internal tooling, so it has a stake in the answer, but you do not need its numbers to see it. Ask around your own company. Someone in sales ops has a dashboard. Someone in HR has an onboarding tracker. Someone in finance has a script that runs every Monday.

For what these tools typically look like, see What People Are Actually Building in 2026. Internal tools are the biggest category by far.

What the cloud assumes, and why it no longer fits

The modern cloud is a brilliant piece of engineering. It was also built for a specific customer. Five of its quiet assumptions now point the wrong way.

1. The builder is an engineer. Cloud consoles assume you know what a VPC, an IAM role and a container registry are. The new builder knows what the quarterly pipeline looks like, and that is the knowledge that matters for the tool.
2. The unit is a product. The cloud is organised around a few big systems that get dedicated teams. Internal tools are the opposite: hundreds of small things, each used by a handful of people.
3. Deploys are rare and reviewed. Pipelines, approvals and staging environments make sense for a product shipped weekly by a team. They do not fit a tool that changes every afternoon because its owner had a better idea at lunch.
4. Infrastructure is somebody’s job. In the classic model, a platform team runs the machines. A marketer with a campaign tracker does not have a platform team.
5. Cost is planned. Cloud budgets assume capacity is sized in advance. Small tools sit idle most of the day, and the cloud already struggles with that: Cast AI found average CPU utilisation in Kubernetes clusters of around 10%, and Flexera’s 2026 State of the Cloud put estimated wasted spend at 29%.

None of this makes the cloud wrong. It makes it a foundation, not a home. Somebody still has to build the house.

Shadow AI apps: what happens when the cloud says no

When the official path is too heavy, people take the unofficial one. They always have. Spreadsheets were the first shadow IT, and nobody stopped using them.

AI makes the unofficial path far more capable. Thoughtworks put “AI-accelerated shadow IT” on its Technology Radar in April 2026 with a Caution rating, warning that informal tools can grow into ungoverned workflows with real security risk and many competing versions of the same solution.

The risk is not hypothetical:

• Access controls go missing. IBM’s 2025 Cost of a Data Breach report found that organisations with high levels of shadow AI paid about USD 670,000 more per breach, and that 97% of those with an AI-related incident lacked proper AI access controls.
• Private apps are not always private. In 2025, Wiz found a flaw in the Base44 platform that let outsiders register for private apps, including internal chatbots, knowledge bases and HR tools, bypassing single sign-on. Wix fixed it within about a day and reported no sign of abuse. The point is not the vendor. It is that internal tools hold internal data.
• Secrets end up in the open. Security firm Escape scanned more than 5,600 public vibe-coded apps and found more than 400 exposed secrets.
• Leaders cannot see it. In Retool’s 2026 governance survey of CTOs, CIOs and CISOs, only 5% said they were very confident they could see everything running in production.

The instinct is to ban it. That does not work, and it throws away the best thing that has happened to internal software in years. The better answer is to give it a home.

What does a runtime for internal tools need?

Start from the tool, not from the server. A small internal tool built with AI needs the following, and each item exists because of something that goes wrong without it.

Identity from the company

Sign-in should come from the identity provider the company already uses, and roles should be inherited from it. If every tool invents its own login, every tool is a new place for an account to outlive the person.

Data with boundaries

A sales dashboard should be able to read the CRM and nothing else. Read-only where possible, no access to HR data at all. Credentials belong in a shared vault, so a data engineer can add the warehouse connection once and everyone else can use it without ever seeing it.

An owner and a lifecycle

Every tool needs a named owner, a history of who changed what, and a way to retire it. Otherwise the useful ones break silently when someone leaves, and the abandoned ones keep running forever.

Cost you can attribute

Per tool, per team, per project. Including the AI calls inside it. A company cannot decide what is worth keeping if it cannot see what each thing costs.

Discovery

If nobody can find what already exists, five teams build the same tool. A shared catalogue, the same idea Thoughtworks recommends, turns one team’s tool into everyone’s.

Small and many, not big and few

Hundreds of tools that each serve a dozen people. Idle tools should rest and cost nothing, and starting a new one should take minutes, not a ticket.

Governance without slowing people down

The trap is to answer every one of those needs with a review meeting. Then the official path is slow again, and people go back around it.

The better model is the one our enterprise page calls freedom at the edge, policy in the Grid. Creators describe what the tool does, what it needs and who it is for. Policy is inherited from the organisation: identity, data rules, which AI models are approved, who can see what. Approvals appear only where the risk is real, such as a tool asking for sensitive data, and low-risk work just flows.

That is how you keep the speed and still know exactly what was created.

How the Grid approaches internal tools

CloudGrid is built as that home. Anyone on a team plugs in what they made, from the AI tool they made it with, and the Grid gives every creation an identity, an owner and an address.

• Spaces let a team organise its tools and inherit visibility, permissions and policy from the organisation. See CloudGrid for teams.
• Permissions separate seeing a tool from using it, operating it or changing it, for a person, a group, a space, a guest, or another tool.
• Visibility is a choice: only you, your space, the whole organisation, invited outsiders, or public.
• Company sign-in (SSO and SAML), a central vault for secrets and variables, and spend controls by team are part of the enterprise offering. Connecting tools to real company systems through the vault is covered in Use your company’s real data.
• Lineage and discovery show what each tool came from, who picked it up, and what grew from it, so useful work compounds instead of being rebuilt.
• Idle apps rest automatically, and budgets and caps can be set per creation, as described on pricing.

For organisations that need it, CloudGrid can also run in your own cloud, so infrastructure, data and security stay inside the company.

Underneath, it is still the cloud. The difference is that nobody on the finance team has to know that.

Key takeaways

• Internal software is now built across the company, not only by engineers, and AI is accelerating it.
• The cloud’s assumptions (engineer builders, big products, rare deploys, a platform team, planned capacity) do not match hundreds of small tools.
• Banning shadow AI apps does not work. Giving them a governed home does.
• A runtime for internal tools needs company identity, bounded data, owners, attributable cost, discovery, and the economics of small and many.
• Good governance is inherited, not reviewed: policy follows identity and context, and approvals appear only where risk is real.

For the individual version of this story, the builder alone with a working app and nowhere to put it, read The Last Mile of Software.