Own your AI product: what to keep when you hire a builder

When you hire someone to build an AI tool for your business, ownership feels like a legal detail. It's not. It's the difference between owning a product and renting one.

Three things matter: your code (the instructions the tool follows), your data (the information you feed it), and your models (the trained patterns the AI learned from your data). If you don't own these clearly, you can't move the tool to a new builder, you can't sell the business with it intact, and you might pay fees forever just to keep using something you already paid for.

Code: who can modify it

You should own the code outright. That means you have the right to read it, change it, copy it, and give it to someone else to maintain.

Some builders will agree to this immediately. Others will offer a middle ground: they own it, but you have a licence to use it. A licence feels safe until you need to make a change and your builder is unavailable, or they go out of business, or you want to switch to someone cheaper. Then you're stuck.

A plumber in Richmond who built a scheduling tool with a contractor learned this the hard way. The contract said the contractor retained ownership. Two years later, when the tool needed a small fix, the contractor quoted 8,000 dollars and a six-week wait. The plumber couldn't modify it themselves or hire someone else to do it quickly. They ended up paying or switching to a different system and losing their custom setup.

The fix is simple: your contract should say you own the code. The builder can keep a copy for their portfolio or reference, but the ownership and the right to modify belong to you.

Data: where it lives

Your customer data, transaction history, and business information should live in a system you control or can access fully. Don't let it sit only on your builder's servers.

Here's why: if the builder's service goes down, your data is unreachable. If you want to move to a different tool or team, you need to export everything cleanly. If there's a dispute, your data is leverage they hold.

A dental clinic in Kelowna worked with a vendor who built a tool to flag patients due for cleanings. The tool worked well, but the patient data lived only in the vendor's system. When the clinic wanted to migrate to their own records software, the vendor charged 3,000 dollars for a data export and took three weeks. The clinic paid because they had no other way to get their own information.

Instead, ask your builder to store data in a database you own or have full access to—your own server, a cloud account in your name, or a standard database format you can read and copy anytime. Make sure your contract includes a right to export all your data in a standard format within 48 hours, at no extra cost.

Models: the trained patterns

If your builder trains an AI model on your data, you need to own that trained model. You should be able to use it, copy it, or give it to a different builder to maintain.

Some vendors will train a model and then charge you a monthly fee to use it, or a per-use fee every time the tool runs. That's recurring revenue for them. It's recurring cost for you, on something you already paid to build.

An accounting firm in Burnaby paid 15,000 dollars to have a vendor train a model to read invoices and extract line items. The contract said the vendor owned the model and charged 0.10 per invoice processed. The firm processes about 2,000 invoices a month. That's 200 dollars a month, or 2,400 dollars a year, forever—on top of the initial 15,000 they already spent. After three years, they'd paid more in fees than the original build cost.

A better deal: you own the model outright. The builder trains it on your data and hands it over to you. If you want them to retrain it later with new data, that's a separate project with a separate fee. But the model itself, once trained, is yours.

The contract matters

None of this happens by accident. You need it in writing.

Your contract should say:

• You own all code, including any custom code written for your project.
• You own all data provided to the builder and all data generated by the tool.
• You own any trained models, and the builder will provide them in a standard, portable format.
• You have the right to export all your data in a standard format at any time, at no cost.
• The builder has no ongoing claims on the code, data, or models after the project is complete and paid.

If a builder balks at these terms, ask why. Sometimes there's a legitimate reason (they use proprietary frameworks that can't be separated). Usually, it means they want to keep you as a paying customer forever. That's fine if you're happy with them. But you should know that's what you're choosing.

Where to start

• Before you talk to a builder, write down what you want to own: the code, your data, and any trained models. Share this list with three potential builders and see which ones agree without negotiating.

• Ask your builder where your data will live and get it in writing. Request a test export of a small sample to confirm you can actually get your data back in a format you can use.

• Have a lawyer who knows software review your contract before you sign. It's 500 to 1,500 dollars well spent. Focus on the sections about ownership, data access, and what happens if the relationship ends.