AWS announced a multiyear joint marketing agreement this week with Superblocks, a 50-person vibe-coding startup that has raised $60 million through a Series A. The product lets a business user describe an internal application in plain language and get a working one. What the deal changes is where that application lands: apps spin up Amazon Aurora databases inside the customer's own private cloud instead of reaching out to something like Supabase, inference runs through Bedrock, and the result sits under the customer's existing IT and security controls. Superblocks CEO Brad Menezes gave the pitch in one sentence. "We're going to bring it to your data inside your private cloud. The big thing about that is data never leaves."
That is a true answer to a real objection. It is also the objection every security officer already knows how to say out loud, which is exactly why it is the one that got engineered away first.
It is not the objection that will cost anybody money.
Read the deal, not the announcement
Start with what was actually signed. This is a joint marketing agreement. Not an acquisition, not a funding round, not a first-party AWS service. AWS ships Kiro for developers and Quick for business users, and neither is a vibe coder in the sense that Lovable or Replit are. Faced with that gap, AWS did not build it and did not buy it. It rented distribution from a 50-person company.
That is a sound move for AWS and a rational one for Superblocks, whose backers include Spark Capital, Kleiner Perkins, Meritech Capital and Greenoaks. AWS's own comment is about as committal as the structure implies: "We support partners where we see strong customer demand and alignment with how customers want to build."
None of that is a reason to pass on the technology. It is a reason to ask the exit question at signature rather than at renewal. If this vendor is acquired, pivots, or the co-marketing quietly lapses, what do you still have? The answer you want is the applications, the schemas and the data, in your account, in a form your own engineers can operate. If the honest answer is a login, you have bought access rather than an asset, and those two things depreciate very differently.
Data residency is not governance
Give the architecture its due, because it earns it. Aurora inside your VPC and inference through Bedrock genuinely resolves exfiltration, third-party processing, and most of the data-flow diagram in a vendor security review. Anyone who has sat through one of those knows how much friction that removes, and it is a materially better posture than a department head pasting a customer list into a consumer tool on a Tuesday. This is the correct shape for enterprise AI and it is not a small piece of engineering.
What it does not touch, because no architecture can, is the second and third year of the application's life.
A private cloud does not say who owns application number 212 when the analyst who generated it moves to a different team. It does not say what happens the next time the source schema changes and nothing in the pipeline tells the app. It does not say where the test is, what the recovery objective is on a database nobody consciously decided to provision, or who reviews the permission set the app inherited from whoever happened to build it.
Each of those has a dull, cheap answer if somebody is assigned to give one, and no answer at all by default. Generating an application does not generate the operating model around it. The security question gets solved first because it has a department attached to it. The lifecycle question stays open because it does not.
Shadow IT with a badge
The failure mode this replaces is familiar. A business unit builds a load-bearing process inside a spreadsheet, or inside an unsanctioned SaaS tool bought on somebody's card, and IT finds out during an incident. Most organizations have been losing that fight quietly for twenty years.
What this deal does is take that behavior, legitimize it, industrialize it, and hand it a production database. On the security axis that is unambiguously an improvement, because the work comes back inside the perimeter where it can at least be seen.
On the sprawl axis it is a step in the other direction, and a larger one than it first appears. The constraint that used to cap the number of internal applications was that building one was hard and required scarce people. Remove the constraint and the count is governed by demand instead, and internal tooling demand at any company of size is effectively unbounded. Nobody has ever run out of ideas for a small app that would make their week easier.
Read that as an argument for sequencing, not as an argument against the technology. Four hundred sanctioned, visible, badly-owned applications is a far better position than four hundred invisible ones. It is simply not the same thing as a governed estate, and the difference between those two outcomes is decided in the first month, not the twelfth.
The lock-in moved down a layer
The strategic argument underneath the deal is the more interesting half of the story, and Menezes states it bluntly: "Any enterprise that is betting on a single model provider, that executive will be fired." On how quickly the buying posture shifted, he is equally blunt: "60 days ago they were like, I want a specific model. It's called Anthropic."
He is not alone in the direction. Satya Nadella has been making a version of the same case, that leaning on one lab for orchestration and app-level infrastructure hands that lab data it can use to study your business and later compete with it. The usage numbers point the same way: open models accounted for 29% of traffic through Vercel's AI gateway last month, with Chinese open-weight options sitting alongside the frontier labs in real production traffic.
The direction is right. It is also worth noticing who is holding the map. Every party currently advising you to decouple from the model sells the layer immediately beneath the model. A hyperscaler that succeeds in commoditizing frontier models keeps the compute, the storage, the network, the identity plane and now the application tier, and the model becomes an interchangeable line item on a bill it already issues.
That is strategy, not conspiracy, and it happens to be good strategy. It only means that "do not tie yourself to one model" and "do not tie yourself down" are two different sentences, and the industry keeps using the first to imply the second. Model portability is real and improving fast. Harness portability is not. Your app definitions, your connectors, your permission model and your generated schemas all live in the harness, and the harness is now the thing you cannot swap on a Friday afternoon.
So the diligence question changed shape rather than going away. It used to be which model. It is now what survives inside your account if you leave, and the model is the easy part of that answer.
The playbook
DMAIC at the strategic layer, disciplined delivery underneath. Six moves, in this order, executed before the tool is switched on rather than after the count gets away from you.
Publish the build tiers before the first app exists. Three of them. Personal tools, team tools, and processes of record. The first two are precisely what this technology is for and should be close to frictionless. Anything a customer, a regulator or a financial statement depends on is not a generated app, it is a system, and it goes to engineering. Write the line down, because it will be argued about, and the argument is dramatically cheaper in advance than during a quarter close.
Register at birth, not at audit. Every generated app records an owner, a purpose, the data it touches and a review date, at creation, as a condition of creation. Five fields. That form is the entire difference between an estate and a mess, and nothing generated is exempt from it.
Read-only until somebody asks. An Aurora instance inside your account is production data with your name on it, and it is now trivially easy to point a generated app at it. Write access should be a deliberate request with a named approver, not the default posture of a generator that is optimizing for a good first impression.
Name a second owner. Any app that survives its first quarter needs a human who is not its author and knows it exists. The single most common route from useful internal tool to open incident is that the one person who understood it changed jobs, and nobody noticed until the thing stopped.
Instrument the estate, not the app. Report the portfolio: total applications, applications with no named owner, applications touching regulated or customer data, applications not opened in ninety days, applications whose owner has left the company. Then retire that last group without ceremony. A sunset process is a feature. It is also the one nobody ever builds, which is why estates only grow.
Buy for exit. Ask in writing, before signing: can we export the app definitions and the schemas in a form our own engineers can run, and where does the generated code actually live? The private cloud tells you where the data sits. It does not tell you whether you can still operate what was built on top of it eighteen months from now.
Our position
This is a good architecture, and the security answer is genuinely better than the alternatives the market spent the last two years offering. Keeping the data and the inference inside the customer's own account is the right shape for enterprise AI, and the hyperscalers will probably win this layer for the straightforward reason that they are the only ones who can offer it credibly.
The trap is the ordinary one, the one that catches competent organizations rather than careless ones. A hard technical constraint gets solved, the solution gets mistaken for the whole problem, and the declaration of victory arrives at the exact moment the work changes from an engineering question into an operating one.
The constraint always moves. It has moved off "can a non-engineer build an internal application," which is now answered and answered well, and onto "who owns the four hundred internal applications we are about to have." That second question does not have a vendor attached to it. It has an owner, a register and a review date, or it goes unanswered until something breaks in front of a customer.
Data never leaves. Good. Neither do the apps.