Do you own your product, or are you renting it?

The question has three answers, because there are three different things being asked about, and a founder who says *we own our product* has usually checked one of them. The substrate it runs on. The expression itself — who, legally, authored it. The route to your customer. Each can be owned or rented independently of the other two, and the combination that hurts is the common one: you own the code, you rent the substrate it cannot leave, and you have never asked what you can assert about either.

Start with the substrate, because there is a definition from 2011 that still does the work better than anything a vendor will tell you. NIST defines three service models and, in each, states plainly what the customer does not control. For software as a service: "The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings." For platform as a service: "The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment." For infrastructure as a service, the consumer "does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components" (NIST, SP 800-145, The NIST Definition of Cloud Computing, September 2011).

The exercise that makes this useful takes half an hour. List the parts of your product — the application, the database, the file storage, authentication, payments, email, the background jobs, the model. Put each on one of the three rungs. Then read out the matching *does not manage or control* clause and ask what you would do if the thing in that clause changed. Most founders have never done this because it feels like an infrastructure question. It is not. It is an inventory of the decisions somebody else is making on your behalf.

There is a fourth rung NIST had no reason to name in 2011, and it is where a lot of first versions now live. On a platform where the workflow builder, the data model and the logic are all the provider's, what you have built is not an application running on rented infrastructure. It is a configuration of the provider's application. Apply NIST's own software-as-a-service language to your own product and the sentence reads correctly: you do not control individual application capabilities, only user-specific configuration. That is a perfectly reasonable thing to have done, and it is a different asset from the one the founder usually believes they are holding.

None of this is a mistake, and the scale of it is worth seeing. In Stack Overflow's 2025 Developer Survey, among 20,070 professional developers answering the question on cloud platforms, containerisation, package managers, build tools and infrastructure as code, Amazon Web Services was named by 45.9%, Microsoft Azure by 27.2% and Google Cloud by 24.3%, with the managed application platforms further down the same list — Firebase 13.3%, Vercel 10.8%, Heroku 5.6%, Supabase 5.4% (Stack Overflow, 2025 Developer Survey: Technology). Renting is the normal condition of modern software, not a failure of nerve. The question was never whether to rent. It is whether you know the terms of the tenancy.

And the event that actually happens is almost never the one founders worry about. Platforms rarely vanish. They reprice, they change rate limits, they move a feature into a higher tier, or they make leaving expensive enough that you stop considering it. The European Union thought this mechanism important enough to legislate against, and its definition is the clearest short statement of how lock-in actually works: switching charges are "charges, other than standard service fees or early termination penalties, imposed by a provider of data processing services on a customer for the actions mandated by this Regulation for switching to the system of a different provider or to on-premises ICT infrastructure, including data egress charges". The Regulation is blunt about the remedy: "From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process" (European Union, Regulation (EU) 2023/2854 (Data Act), Articles 2 and 29).

Whether that Regulation binds any given provider you use is a question for a lawyer and your contract, and this is not the place to answer it. What the text is useful for regardless of jurisdiction is that a legislature sat down and wrote out the minimum terms under which leaving a platform is actually possible — which is precisely the list nobody negotiates when they sign up in ten minutes with a card.

Those minimums are worth stealing as a checklist. The Regulation requires a maximum notice period for initiating a switch "which shall not exceed two months"; a minimum period for retrieving your data of "at least 30 calendar days" after the transitional period ends; and where the standard transitional period is technically unfeasible, an alternative one which "shall not exceed seven months". It also obliges the provider to give the customer a reference to "an up-to-date online register... with details of all the data structures and data formats" in which the exportable data is available, and to disclose the "restrictions and technical limitations which are known to the provider" (Articles 25 and 26 of the same Regulation).

Turn that into three numbers per dependency and the exercise stops being abstract. For each platform your product depends on: how much notice would you get before a material change to terms; how long would you have to retrieve everything; and where is the document that describes the format you would get it in. Most founders can fill in none of the three for any of their dependencies. That is the finding — not the exercise.

Filling them in exposes the distinction that matters more than any of the numbers: rented substrate versus rented capability. Rented substrate is compute, storage, a database engine, a CDN. It is expensive and annoying to move and it is unambiguously movable, because what you are running is yours and it runs elsewhere. Rented capability is different. When the business logic lives in the provider's runtime, there is no export, because there is no artefact to export — an archive of your configuration is not a program, and it does not run anywhere but there. The two decisions that keep a bought component replaceable are set out in bespoke or off-the-shelf, and they are cheap to make at the start and expensive to retrofit. A student information system unifying 150+ college branches is the shape of the alternative: one data model you own, per-branch isolation and audit trails enforced in the platform rather than in a vendor's tenancy settings, which is what AI data infrastructure services exists to build.

Now the second ownership question, and it is the one that catches founders who built fast with AI tools. Not *can we use this code* — you can — but *what can we assert about it*. The US Copyright Office addressed this directly. Its conclusions: "Copyright protects the original expression in a work created by a human author, even if the work also includes AI-generated material"; "Copyright does not extend to purely AI-generated material, or material where there is insufficient human control over the expressive elements"; and "Based on the functioning of current generally available technology, prompts do not alone provide sufficient control." The reasoning is worth the sentence: "prompts alone do not provide sufficient human control to make users of an AI system the authors of the output. Prompts essentially function as instructions that convey unprotectible ideas" (US Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability, January 2025).

Read what that does and does not say, because both halves get exaggerated. It does not say you cannot use, sell or license software a model helped write. It does not say somebody else owns it. It says that copyright — the thing you would rely on to stop a competitor copying your product wholesale — attaches to human expression, that the analysis is case by case, and that a transcript of prompts is not, on its own, the evidence you would want to be relying on.

The same report says what is already yours, and it is more than founders assume: "Human authors are entitled to copyright in their works of authorship that are perceptible in AI-generated outputs, as well as the creative selection, coordination, or arrangement of material in the outputs, or creative modifications of the outputs." The practical consequence is administrative rather than legal, and nobody does it. The record of human contribution — commit history with real authorship, the specification somebody wrote, the review that changed something, the modifications made after the generation — is an asset, and a codebase generated in a weekend and pushed as one commit has thrown that record away. Keeping it costs nothing at the time and cannot be reconstructed afterwards, which is exactly the property that makes people skip it.

Where this surfaces is not litigation. It is the intellectual-property representations in your first serious customer contract and the technical diligence in your first serious funding round, both of which ask you to state what you own and how you know. It is the same class of question as who owns an AI system after it ships, which names the five ownership jobs that need a human beside them at launch — and the model relationship is one of them, because the provider can retire the model underneath you on a date it has already published.

The third question — the route to your customer — is short but not small. If a platform sits between your product and the people who pay for it, then discovery, the review that gates your release, the account that can be suspended and the appeal you may not get are all rented too, and none of it is in your repository. The artefacts that establish the first two kinds of ownership at handover time are listed in the handover you must receive, and the accounts question is the sharpest item on that list.

On Monday, write the rent roll: one page, one row per dependency, three columns — what would I lose, how much notice would I get, and what could I still run thirty days after it withdrew. Most rows will be blank the first time and that is the point of writing it. A startup software development company worth hiring will ask for that page before it proposes architecture, because the answers change what should be built and what should simply be rented properly. The two-week AI readiness assessment produces it as a deliverable alongside the roadmap, and the free production-readiness diagnostic will name the failure modes in what you have already shipped — including the ones that are somebody else's platform rather than your code.