Why Clients Should Own Their Source Code
If code and access stay with the vendor, you’re a tenant of your own digital asset. Source ownership cuts business risk and restores negotiating power.
Ali Mortazavi
Founder, Paradise Code
Your site is an asset, not a delivered file
Domain, customer data, pricing logic, and ops panels are company value. If you only have “what’s on the vendor’s hosting,” switching suppliers means begging or rebuilding.
Ownership means a repository under your org, admin access to hosting/cloud, and rights to use and modify without separate permission—except third-party library licenses, which must be explicit.
Take vendor risk seriously
Agencies can shut down, raise prices, or deprioritize you. Without source, your options are zero. With source and a deploy runbook, a second team can engage in days—not months.
That optionality also keeps renewal pricing honest. Operational lock-in is the most expensive lock.
What the contract must say
IP transfer for custom work after each paid phase; git access from sprint one; secrets in your password manager; dependency and license inventory; and a deploy runbook deliverable. Reject vague “delivered when the project is finished” if finished isn’t defined.
For the vendor’s preexisting templates or libraries, demand a perpetual non-exclusive license—or a replaceable open alternative.
Ownership without maintainability is hollow
Messy source without tests, README, or a runnable environment is nominal ownership. Put in acceptance criteria: the project boots on a fresh machine with documented commands.
Spaghetti on your repo is still debt—but at least transferable debt. Ask for quality samples and branch/PR standards.
Cloud models and “source as a service”
Some vendors sell multi-tenant product and don’t give source; that’s SaaS and fine if data export and APIs are clear. The problem is projects sold as “custom” but locked to the vendor’s closed platform.
Ask: if the contract ends, can I run the same system elsewhere? If no, price it as long-term rent—not an asset purchase.
A first-30-days checklist
Day one: repo and access. Each sprint: version tags and release notes. Monthly: backup and restore test. Phase end: written IP transfer confirmation. That’s professionalism, not distrust.
Paradise Code defines custom projects around clear client ownership—because long-term maintenance stays healthy only when trust is mutual and exit is possible.
Frequently asked questions
Can a vendor hide the code?
For SaaS products, yes. For custom work you fund, hiding code should be a red flag unless the contract clearly says otherwise.
Whose GitHub account should host the repo?
Preferably your organization, with the vendor as collaborator. If it starts on theirs, put a timed transfer in the contract.
Aren’t open-source dependencies enough?
No. Your business logic lives in custom code; library licenses don’t replace product ownership.
Insights
Need these ideas implemented in your product?
Paradise Code supports you from consult to full delivery.