Should you own your code and data when you build with AI? For most of software's history, the question barely came up, because the hard part was building it. Custom software cost so much that renting someone else's product per seat, per month, forever, was often the only sensible choice.
AI coding agents have changed that. A small team, or one determined founder, can now ship in a weekend what used to take a quarter. When building gets cheap, the question that matters shifts from "can we build it?" to "who owns what we built?"
Our position is simple: if your business runs on it, you should own it. That means the code, the database, and increasingly the AI setup that writes and maintains both.
What "owning it" actually means
Ownership is easy to claim and easy to fake. Here's a test you can run on any system your business depends on, whether you built it, bought it or had it built:
- The code. Do you have the full source in a repository you control, with the right to change it and deploy it anywhere?
- The data. Can you export everything in a standard, structured format without asking permission or paying a fee to leave?
- The infrastructure. If your host disappeared tomorrow, could you deploy somewhere else in days rather than months?
- The know-how. Is the way the system is built and run written down (README,
AGENTS.md, migrations, runbooks) instead of living in one vendor's head? - The economics. Does the cost stay sensible as you grow, or does it scale with every user you add?
If you answer "no" to several of these, you're renting. Renting is a fine choice when it's deliberate. It's a problem when it happened by accident.
Why AI makes this more urgent, not less
1. AI amplifies whatever you own. A coding agent working in your own repository can refactor, extend and fix your system on demand. An agent can't do much with a closed SaaS product beyond what its API allows. The more of your stack you own, the more an AI agent can do for you.
2. Your data is your edge. Models are available to everyone. Your customer history, your conversions and your operational data aren't. Most worthwhile AI features, like predicting which customer will churn or which ad will perform, need that data in a place you control and can query directly.
3. Vendors change the rules. Even good platforms change things. For example, Supabase is deprecating its legacy anon and service_role API keys by the end of 2026 in favor of new key types (Supabase API keys). That's a reasonable change with a documented migration path, but it shows that every dependency comes with maintenance you don't schedule. When you own the code, you can make those changes on your own timeline.
4. Your AI setup is becoming an asset too. Your AGENTS.md, your agent skills and your MCP connections hold real knowledge about how your business builds software. Keep them in open formats. Agent Skills is an open standard that works across many agents (agentskills.io). AGENTS.md is read by a long list of coding tools (agents.md). And MCP now sits under the Linux Foundation's Agentic AI Foundation (MCP blog). If your workflow lives in these files, you can switch AI tools without starting from scratch.
The legal angle (especially in Quebec)
Ownership isn't only a strategy question. For Quebec businesses, it's increasingly a compliance one.
Since September 22, 2024, Quebec's Law 25 has given individuals a right to data portability. On request, an organization must provide computerized personal information collected from that person in a structured, commonly used technological format (our translation of the French "format technologique structuré et couramment utilisé"), or send it to an organization they authorize (Commission d'accès à l'information). The CAI also says businesses must make sure that any new project to acquire, develop or overhaul an information system can provide personal information in such a format, and that requests follow the same 30-day deadline as other access requests (CAI guidance).
Law 25 also requires, since September 2023, a privacy impact assessment before personal information is communicated outside Quebec, and privacy settings that default to the highest level of confidentiality (CAI, main changes).
You can't meet these obligations well if you don't know where your data lives or can't export it cleanly. When you own your database, that's a query and an export. When you don't, it's a support ticket and a wait. For the French-language side of Quebec compliance, see our guide to building a bilingual app for Quebec. (This is general information, not legal advice. Talk to a professional about your situation.)
A checklist to own your code and data
You don't need to rebuild everything. Start with what matters most:
- Repository: the source lives in a Git organization your company owns, not in a contractor's or a no-code builder's personal account. New to Git? Start with our Git and GitHub basics for vibe coders.
- Database: use a standard engine you can run anywhere. Postgres, for example, ships with
pg_dumpfor exporting a database (PostgreSQL docs). Check that you can actually export and restore it. Our guide to backing up and exporting a Supabase database walks through it. - Accounts: the hosting, database, domain and payment accounts are in the company's name, with at least two admins.
- Secrets: keys live in your platform's secret storage, and you know how to rotate each one.
- Docs for humans and agents: a README, an
AGENTS.mdand migrations in the repo. If a new developer, or a new AI agent, can't get the project running from the repo alone, you don't fully own it yet. - Exit test: once a year, run a "what if we had to move?" drill. Deploy a copy somewhere else. You'll learn more from that than from any contract.
The trade-off, honestly
Owning your software means taking on responsibility for it: updates, security patches, backups, monitoring. Some tools are worth renting. Email, payments and accounting are rarely where you want to be different.
The line we draw is this: rent commodities, own your core. Your core is the system that holds your customer relationships, your operations data and the workflows that make you different. That's the part to own.
Keep reading
- How to back up and export your Supabase database
- What is AGENTS.md, and how to write one
- AGENTS.md starter template for Next.js and Supabase
FAQ
What does it mean to own your code and data?
It means the full source is in a repository your company controls, your data exports in a standard format without permission or fees, and you could redeploy elsewhere in days.
Is renting SaaS always a mistake?
No. Renting is fine when it is deliberate, for commodities such as email, payments and accounting. The risk is renting your core system by accident.
What does Law 25 say about data portability?
Since September 22, 2024, a Quebec organization must, on request, provide computerized personal information collected from a person in a structured, commonly used technological format. This is general information, not legal advice.
How do I test whether I really own my stack?
Run an exit drill once a year: deploy a copy of the system somewhere else using only the repository, the docs and a data export.