You own everything: why we transfer code, prompts and models

AI vendor code ownership is the clause most buyers skim and most regret skimming. Our position is simple: on payment, the client owns the code, the infrastructure configuration, the prompts, the evaluation suites, any fine-tuned weights and the documentation. Where we bring pre-existing internal tooling into a build, it is licensed to the client inside the deliverables, perpetually and without fees, so the system keeps working whatever happens to us. This article explains what that means line by line, why we chose it over the licensing models common in the market, and what it costs us.

What "you own everything" covers

Why we transfer rather than license

Lock-in is a business model we do not want

Many agencies earn their margin in years two and three, when a client cannot leave because the vendor holds the repository, the prompts or the model. We think that is a poor way to keep a client and a worse way to build software, because a team that cannot be fired has no reason to stay sharp. We would rather be kept because the Care Plan is good value than because leaving is impossible.

The client's data made the system

An AI feature is mostly shaped by the client's data: their documents, their conversations, their labelled cases, their tone. The prompts encode their policies. The evaluation set is their history. A fine-tuned model is a compressed copy of their examples. Claiming ownership of any of that would be claiming ownership of the client's own knowledge with a thin layer of our work on top. It is theirs.

Fixed price needs a clean end

Our programs are fixed price and fixed date. A fixed-price engagement needs a clear finish line, and a finish line where the vendor still holds the keys is not finished. Ownership on payment lets both sides walk away clean, which is what makes the fixed price honest. The programs and what each includes are listed on the pricing page.

How the transfer actually happens

Ownership is not a clause; it is a set of habits during the project. The repository is created in the client's organisation on the first day, and every commit lands there. Cloud, model-provider and vector-database accounts are created in the client's name with the client's billing details, and our engineers are added as members. Secrets live in the client's secret manager. Prompts are files in the repository, not rows in our tooling. Evaluation suites run from the client's CI. At handover we remove our access, and the client can verify that nothing stops working.

The handover pack has a fixed shape: an architecture note, a runbook for deploying and rolling back, the evaluation report from the final run, a list of every third-party dependency with its licence, a cost model for the running system, and a list of known limitations. We ask the client's engineer to deploy from the runbook while we watch, without our help, before we call the project done.

Where our own tooling comes in

Over many builds we have accumulated internal components: an evaluation runner, a model-routing layer, a document-processing pipeline, observability helpers. Reusing them is how a fixed price stays low. When one goes into a client build, it goes in as source, under a perpetual royalty-free licence that permits modification and internal use. What the client may not do is resell the component on its own as a product, which is the only restriction. Third-party open-source libraries stay under their own licences, listed in the dependency inventory, and we avoid licences that would constrain a commercial product.

What this costs us, honestly

It costs us repeat revenue we could have had by holding the keys, and it costs us the option of a hosted product built on client work. It also means we sometimes lose a debate with a client's procurement team who expected to negotiate for something we had already given. We accept that because the alternative undermines everything else we say about evals, shadow mode and honest scoping: a vendor who owns your prompts has an incentive to keep them opaque, and opacity is the enemy of measurement.

A worked example

A B2B SaaS company engaged us for an in-app copilot for their field-service product. Their previous vendor had built a chatbot on the vendor's own platform; when the relationship ended, the prompts, conversation logs and the retrieval index stayed behind, and the client started from nothing. This time the repository, the model-provider account and the vector store were the client's from the first day. Prompts were committed beside the code with the evaluation results in the pull request. At the end of the build their own engineers deployed a prompt change through the eval gate without us in the room. The project outline is in the in-app copilot case study, and the pattern applies to any SaaS copilot build.

Team and timeline

Ownership adds no time to a project because it is how we work from day one, not an extra phase. In a Launch 6 AI-Accelerated MVP, six weeks fixed at $26,500 to $45,500 (from ₹17,60,000), the repository and accounts are set up in week one, and the handover walkthrough is in week six. The client needs someone with authority to create cloud and provider accounts in the first week; that is the most common cause of delay and the only ownership-related task we cannot do for you. Legal review of the assignment clause usually takes a few days and we supply the wording up front so it runs in parallel with Sprint Zero.

Before you start: a checklist

• Ask any vendor, in writing, who owns code, prompts, evaluation data and weights, and when ownership passes
• Create your own repository, cloud and model-provider accounts before the first day of the build
• Ask for the vendor's list of pre-existing components and the licence terms for each
• Require prompts to be versioned files in your repository, not entries in a vendor tool
• Require the evaluation suite as a runnable asset, not a PDF
• Ask for a dependency inventory with licences before acceptance
• Plan a handover deployment performed by your engineer, not the vendor's
• Decide who holds admin on every account after the vendor leaves

Questions clients ask

• Does ownership pass before final payment? Code is in your repository throughout, so you hold it physically from day one. Legal assignment completes on payment of each milestone, which is standard and fair to both sides.
• Can we open-source what you build for us? Yes, for the parts you own. Our licensed components would need to be replaced or excluded, and we will tell you which files those are.
• What if you use our project to improve your internal tools? Generalised improvements to our tooling stay ours; anything specific to your domain, data or product stays yours. The contract says exactly that.
• Do you keep a copy of our data? No. Golden sets and logs live in your accounts, and our access ends at handover.

Glossary

• Assignment: the legal transfer of ownership of a work from its author to another party, here from us to the client
• Background IP: tools and components a vendor owned before the project began and brings into it
• Foreground IP: everything created during the project for the client; ours is assigned on payment
• Perpetual royalty-free licence: a permission to use something forever with no ongoing fee; how our background IP is delivered
• Dependency inventory: the list of third-party libraries in a system with their licences, delivered before acceptance
• Handover pack: the architecture note, runbook, eval report, cost model and limitations list that closes a project

Related reading

The contract detail is in who owns the code, prompts and models, and the wider stance is on our about page. For the licences we accept in a dependency inventory, the Open Source Initiative's licence list on GitHub is the reference we point clients to.

You paid for it, your data shaped it, and you should be able to run it without us; anything less is rent dressed up as a service.