Keep control of your AI product when you hire a builder

When you hire someone to build an AI product for your business, you are buying more than code. You are buying the right to own what gets made, to understand how it works, and to walk away if the relationship sours or the vendor raises prices.

Many founders and product leads skip this conversation because it feels premature. The vendor seems trustworthy. The project feels small. But ownership questions are easiest to answer before work starts and hardest to fix after launch.

Here is what you need to own, and why.

Own your code

This is the simplest one. Every line of code written for your product should be yours. Not licensed to you. Not held in escrow. Yours.

If your vendor builds a tool that reads your customer intake forms and files them into your CRM, you own that code. You can read it, modify it, hand it to another developer, or run it on your own servers.

Why this matters: code is how the tool works. If you don't own it, you can't fix bugs without asking permission. You can't add a feature without negotiating. You can't leave without rebuilding from scratch.

A vendor who balks at this is telling you they plan to keep you dependent.

Own your data

Your customer records, your documents, your transaction history, your files—these belong to you. They should live somewhere you control or can access anytime.

This is not always obvious. Some vendors store your data on their servers for convenience. That is fine if you can export it all, in standard formats, whenever you ask. If they make export slow or expensive, or if they hold it hostage during a dispute, you have lost leverage.

A property manager in Surrey learned this the hard way. Her intake tool worked well for two years. When she asked to export her tenant records to switch platforms, the vendor charged 8,000 dollars and took six weeks. She paid it, but she never forgot.

Get this in writing: you can export all your data in a standard format (CSV, JSON, PDF) anytime, at no cost, within 48 hours.

Own your trained models

This is the one most founders don't think about. When a vendor trains an AI model on your data—teaching it to recognize your invoices, or categorize your customer types, or predict your churn—that model is a product you paid for.

You should own it. You should be able to download it. You should be able to run it on your own servers or hand it to another vendor.

Why this is tricky: some vendors train models that only work on their infrastructure. They do this on purpose. It makes you stick around. But it also means you are renting access to your own intellectual property.

A distributor in Calgary paid 45,000 dollars to train a model that predicted which suppliers would ship on time. After six months, the vendor raised their monthly fee by 60 percent. The distributor wanted to leave, but the model only ran on the vendor's servers. Moving would mean starting over. They paid the increase.

If you own the model, you own the choice.

How to get this in writing

Before you sign anything, ask your vendor for a clear statement on ownership. It should cover:

• All code is your property, delivered and licensed to you exclusively.
• All data you provide remains your property and can be exported anytime.
• All trained models are your property and can be downloaded and run independently.
• If the relationship ends, you get everything within 30 days.

If the vendor resists, ask why. A good answer sounds like: "We build this way for all clients." A bad answer sounds like: "We need to protect our intellectual property" or "That is not how our platform works."

If they resist hard, walk. There are builders who will do this.

The cost of portability

Building for portability costs more. Not a lot more. Typically 5 to 10 percent of the project budget. You are paying for:

• Clear code documentation so another developer can maintain it.
• Data exports tested and working before launch.
• Models saved in standard formats, not proprietary ones.
• A handoff process if you need to move.

A 12-person software company in Gastown budgeted 80,000 dollars to build an AI feature. Adding portability added 6,000 dollars. Two years later, they switched vendors. The portability work saved them 40,000 dollars in rebuilding costs.

It is the best insurance you can buy.

Keep a person in the loop

Do not let this become a legal checkbox. Have a conversation with your vendor's leadership. Say: "We want to own what we build together. Can you commit to that." Listen to how they answer. Do they sound defensive or confident. Do they explain it clearly or dodge.

A vendor who is comfortable with this has nothing to hide. They know their work is good enough to stand on its own.

Where to start

• Write down what you want to own (code, data, models) and add it to your vendor contract as a section before you sign anything. Use plain language: "The client owns all code, data, and trained models created during this project."

• Ask your potential vendor directly: "Can we own the trained models and run them on our own servers if we want to." Write down their answer and ask for it in writing.

• Budget 5 to 10 percent extra for portability and ask your vendor to explain what that covers: documentation, data exports, model formats, and handoff process.