Who owns the code when an agency builds your system, and what to get in writing.

A clause that says the code belongs to you does less than it sounds like it does. You can own every file and still be stuck. Owning a folder and being able to do anything with it are separate problems, and only the first fits neatly into a contract.

The worry behind the phrase lock in is usually about a particular week, the one where the builder stops answering. Something breaks, or the company starts selling abroad and the system needs to know. At that point the question is whether anybody else could keep the thing running and change it without guessing, and a clause about intellectual property has nothing to say about that.

So it is worth testing a contract against that week before signing it. Three things decide the answer. One of them has to be settled before the system exists at all, and the other two are about what you are handed and whether you could use it. OCTYN builds systems and then runs them, so the question applies to it as much as anyone, and its own answers are quoted below.

Where it runs, written down first

Where a system runs sounds like a detail for engineers. It decides most of what owning the code is worth. If the parts that do the work sit on accounts the builder holds, the code you own describes a machine you cannot reach, and moving it later becomes a project with its own price.

OCTYN writes down where a system will run before anything is built. A decision nobody makes at the start gets made anyway, by whoever sets up the first server.

The outreach system OCTYN runs for an independent craft retailer is a fair example of why that document needs more than one line. It has two parts that share a database and nothing else. A heavy part works at night, finding brands and drafting emails, and a light part is always on, on a small server of its own, doing nothing except sending what is due. Its mail credentials are not stored on that server. It fetches them when it needs them. And a change to the scheduling rules is not live until it has been deployed there, which a new owner would otherwise discover by editing a rule and watching nothing happen.

So the document worth having names each part and the account it runs under, and says where its credentials live when nothing is using them. Whose name is on those accounts matters too. If it is the builder's, the contract should say how that moves to yours, and when.

What the contract should call yours

Asked who owns the system, OCTYN answers with one word, yours, and then a list: the client's data, specs, configuration and system code. OCTYN's general tooling and methods stay its own.

That second sentence is the one to read slowly, in any contract and in OCTYN's too. A firm that builds more than one system will reuse things, and there is nothing wrong with that as long as you know where the line falls in the system you are paying for. Ask for it by name. Which of the parts that run for you are yours outright, and for anything that is not, what happens to it if you part ways?

A short version of what to get in writing: - where each part runs and under whose account, settled before the build - your data, and the shape it is stored in - the specs, meaning what the system is meant to do, written down - the configuration, every value and file a person is expected to change - the system code, with its tests beside it - documentation good enough for someone else to take it over

Configuration is the easiest item to leave off, and in a system built to be changed it is where most of the changing happens. In the craft retailer's system the target criteria sit in a file per company: sources, weights, thresholds, categories, market. Daily volume, the split between the home market and abroad, inbox limits, send windows and follow up timing are all values. Most changes to that system are settings. A contract that hands over the code but treats those files as the builder's working papers has handed over the part that moves least.

The page on what it costs to change a workflow six months later sorts change requests into four buckets, from a settings change up to a rebuild, and a settings change is the bucket measured in minutes, with no new code and no review. If the settings are yours and written down, it stays that way after the builder has gone.

Documentation good enough to take it over

After launch OCTYN runs the system, and the client can take it over, with the documentation to do it. That last part is easy to promise. One test of it is whether a capable stranger could pick up the documents on a Monday and make a safe change by Friday.

For the craft retailer, most of what would make that possible is unglamorous. The gates are plain code with tests beside them, so a new geography signal is one rule with a test and a new banned phrase is a line in a list. Every guard is written into the operating notes beside what it prevents, with the date something went wrong. One goes back to 10 August 2026, when 115 follow ups came due across a weekend and nothing picked them up, because the check only looked at today. Somebody new who reads that knows why the scheduler moves weekend dates to Monday, and is less likely to tidy the rule away as clutter.

OCTYN's write up of that system is just as plain about its limits. Everything in it assumes email, so a new channel would reuse the finding, scoring and drafting and still need its own sending part. A daily volume far past 25 is the one case marked for a rebuild. Anyone taking the system over wants to have read that before promising a new channel to somebody.

None of this argues for taking a system over on the day it launches. An operating partner stays to run what it built, so the people who wrote a rule are still around to explain it, and most of the difference from a dev shop shows up the month after launch. The documents are for the other case. A contract is where you make sure they exist while everyone is still on good terms.

OCTYN's paid first engagement, the Consult, comes before any build is priced, and it is a reasonable moment to ask for all of the above. A builder who has thought about being replaced will have most of it written down already.