Someone on your team is about to build something with an AI coding tool. A quoting sheet that fills itself in, a dashboard that pulls from three systems, a script that files the invoices. They may already have started. This is the best thing to happen to small companies in years, and the right answer is yes.
The question is when to ask the questions. Everything else on this site is about the thing after it exists: the six things to require before the business relies on it, the four files to ask for once you find it, the infrastructure checklist that turns a prototype into a system. All of that is homework on something already built, and by then the awkward answers already exist: the personal account, the customer list in a chat window, the one person who knows how it works.
This is the conversation before that. Fifteen minutes, nine questions, and a matching line for the builder so they arrive with the answers. It is written for both of you to read. If the builder is outside the company, use the hiring version instead; most of it is the same, with a contract on top.
First, which tier
Not every tool needs every question. Decide the tier first, and the list shrinks to fit.
Personal shortcut. Only the builder uses it, and nothing happens if it stops.
Questions 1 to 4, then go. A script that renames files or drafts a weekly summary does not need a second person.
Team tool. Other people will rely on it, or it runs on a schedule.
All nine questions. This is the tier most weekend tools land in by their second month, whether or not anyone decided that.
Customers or money. Anything a customer sees, anything that moves money, anything that would be missed within a week.
All nine now, and the infrastructure checklist before anyone relies on it. The AI policy’s rule applies: a person checks it and their name goes on it.
The nine questions
Each one has the manager’s question and the line the builder checks before asking. Click any question for why it matters.
1. "What problem, and how often does it happen?" Builder: I can name the task, how often it happens and the time it costs.
The answer is a task and a number: “the Monday reconciliation, about two hours a week”. Not “it would be really useful”. A range is fine. If the number is small, that is still a yes; it just belongs in the personal tier.
2. "Is there already a tool for this?" Builder: I looked at what we already pay for.
Most companies already pay for software that does the thing, badly configured. Ten minutes checking saves a build and, more often, finds that the existing tool needs one setting changed. Where it does not, the builder now knows what the new thing has to beat.
3. "Who will rely on it?" Builder: Just me, my team, or customers and money.
This sets the tier. Be honest about the second month, not the first week. A tool built for one person that the team starts using is a team tool, and it has quietly skipped questions 5 to 9.
4. "Which AI tool, on whose account?" Builder: The company's plan, not my personal one.
This is the question most companies never ask, and the one that matters most. On personal plans, the big AI tools can use what is typed into them to train future models: Claude’s Free, Pro and Max plans do when the setting is on, and Copilot’s Free, Pro and Pro+ plans do unless the user opts out. Business and commercial plans do not. A personal account is also a login the company cannot see or recover when the person leaves. If the company has no business plan yet, this conversation is the reason to get one. The hiring playbook has the plan-by-plan detail.
5. "What data will it touch?" Builder: No customer or staff data without a yes from you.
A named list: which records it reads, which it writes, and whether any of it goes into an AI tool. The builder needs test data to work with, not the live customer list pasted into a chat to “show the AI an example”. Canada’s privacy regulators ask that personal information go into generative AI only where authorised; this is where the authorising happens. The one-page AI policy says what may and may not go in; this question applies it to one tool.
6. "Where will it run, and where do the passwords go?" Builder: A company account, with keys outside the code.
Hosting, database and any third-party service under a company account from the first day, with the builder invited in. Passwords and API keys in the platform’s secret store or a password manager, never in the source and never in a chat. The AI tool should not be able to read them either. Decided on day one, this is ten minutes; decided at handover, it is a migration.
7. "Who is the second person?" Builder: Someone who will test it and could take it over.
Named now, not found later. They do two things: check the tool against what the business asked for (the refund, the end of the month, the customer with two accounts), and know where the notes are if the builder changes roles. They do not need to code. Without a second person the tool has a bus factor of one, and the company does not own it, whatever the contract says.
8. "How much of your time is this worth?" Builder: I will stop and check in at that point.
AI tools make the first version fast and the fifth version endless. Agree a budget in hours before the first one: “a day, then show me”. The check-in is where the tier gets reconsidered, because the thing that took a day and works is now about to be relied on.
9. "What happens if you move roles?" Builder: I will keep the four files up to date as I go.
A README that says what it does and how to run it, a data map, a deploy note that says where it runs and what keys it needs, and a handoff draft written for someone who has never seen it. Written as the tool is built, a paragraph at a time, not reconstructed the week the builder leaves. What a company keeps when the coder leaves is why the reasoning matters more than the code.
Who owns it
Simpler than with an outside builder, with one trap. Canada’s Copyright Act says that where a work is “made in the course of his employment”, the employer “shall, in the absence of any agreement to the contrary, be the first owner of the copyright”. For a tool built on company time, on company accounts, for the job, that is you.
The trap is the side project. In March 2026 the Court of Appeal for Ontario upheld an employee’s ownership of software he wrote largely outside business hours, on his own equipment, with no written employment contract and no instruction to build it (Nexus Solutions Inc. v. Krougly). The factors the court weighed are the ones questions 4, 6 and 8 settle: where it was built, on whose materials, with what direction. The firms that reported the case gave the same advice: put a clear IP assignment clause, and a waiver of moral rights, in the employment agreement.
Underneath both sits the open question of whether code an AI wrote has copyright at all; the hiring playbook covers it. In practice, ownership here is the company account, the second person and the four files. None of this is legal advice; have the clause checked.
The two lists on one page
For the wall, or the first page of the tool’s README.
| The manager asks | The builder checks first | Tier |
|---|---|---|
| What problem, and how often? | I can name the task, how often, and the time it costs | All |
| Is there already a tool for this? | I looked at what we already pay for | All |
| Who will rely on it? | Just me, my team, or customers and money | All |
| Which AI tool, on whose account? | The company’s plan, not my personal one | All |
| What data will it touch? | No customer or staff data without a yes | Team and up |
| Where will it run, and where do the passwords go? | Company account, keys outside the code | Team and up |
| Who is the second person? | Someone who will test it and could take it over | Team and up |
| How much of your time is this worth? | I will stop and check in at that point | Team and up |
| What happens if you move roles? | I will keep the four files up to date | Team and up |
Customers or money: all nine, then the infrastructure checklist before anyone relies on it.
How to say yes
“Yes. Company account, test data until we talk again, a day of your time, then show me and Priya.” That sentence covers questions 4 to 8, takes fifteen seconds, and turns a weekend builder into someone who knows how systems are kept running. The builder who hears it once asks the questions themselves the next time.
Changelog
- 2026-10-03: first version, published the same day.