Devesh JoshiCo-founder, product
Nine years building AI platforms serving 12,000+ engineers. LLM platforms, agentic systems (MCP), and multi-model safety evaluation.
What “you own the codebase” actually means after launch
Most agencies say it. Fewer mean all of it. The specific things to check before you sign, and what they cost you if nobody checks.
The claim is nearly universal. The substance is not
Almost every agency says you own the code. The sentence is doing a lot of quiet work, because owning a repository is not the same as being able to run what is in it.
The question worth asking is narrower: if this relationship ended on Friday, what could another engineer do on Monday?
Five things to check before you sign
Whose cloud account is it deployed to. If the infrastructure lives in the agency's account, you own source code you cannot deploy without them.
Who holds the API keys and the domain. These get overlooked precisely because they are small, and they are the fastest way to be locked out of your own product.
Is there a proprietary layer. Ask directly whether any part requires a licence, a hosted service, or a runtime the agency controls. A framework everyone uses is fine. A private orchestration layer is a subscription with extra steps.
Does documentation come with it. A repository with no architecture notes is technically yours and practically somebody else's, because the only people who can change it safely are the ones who left.
What happens if you stop mid-build. Stage boundaries matter — you should keep everything built up to the point you stopped.
How we answer it
Your repository, your cloud accounts, your keys. There is no proprietary layer you would need us to keep running, and if you stop at a stage boundary you keep everything built to that point, documentation included.
We would rather you stopped at stage two than spent another eight weeks on something you had lost confidence in.
Why an agency would build it this way
Lock-in produces renewals from clients who wanted to leave. That is a worse business than one where clients stay because leaving was always available and they chose not to.
It also changes what gets built. Code written knowing another engineer will read it next year is better code than code written on the assumption nobody else ever will.
Topic Focus & Target Concepts
This is the work behind our build practice — pitch-ready MVPs through to production applications, on a stack chosen for whoever maintains it after we leave.
Product and web app buildsRunning into this in your own stack? Twenty minutes, no deck.
Book the call