Independent Work in AI: Scoping Projects and Saying No

Freelance and contract work in AI rarely fails because the code is beyond the person. It fails because the project was never clearly bounded. A client asks for a classifier, then for a dashboard, then for a model that explains its decisions, and the fee was set for the first request alone. The habits that protect independent work are mostly about writing things down before the first line of code is written.

Write the scope before the estimate

A scope document is a short statement of what will be delivered, for whom, and how it will be judged. It names the inputs the work will use, the outputs the client will receive, the format of those outputs and the people who will review them. It also states what is excluded, and the exclusions matter more than the inclusions. A scope that says the classifier will be trained on data the client provides, and that cleaning data from other sources is not included, prevents a dispute that would otherwise arrive in week three.

Write the scope before you estimate. It is tempting to set a price first and then fit the scope to it, but the reverse order keeps you honest. If the scope turns out to be larger than the fee, you learn that before accepting the job, and you can propose a smaller first phase instead.

Define done in observable terms

Done is the most important word in an independent contract, and it is often left undefined. Define it by something a third party can check. A model meets an agreed accuracy on a held-out set the client has approved. A pipeline runs on a schedule and writes its results to a stated location. A report is delivered with an explanation of its limits. Avoid done when the client is happy, because that standard means the work is never finished. Write down the test, the sample and the person who checks it.

Agree also on what happens when the test is not met. A common approach is a fixed number of revision rounds, after which further changes are priced separately. Put that in the document. It turns a difficult conversation into a routine one.

Price by outcome or by hours

Hourly pricing is simple to explain, but it can reward slowness, while fixed pricing rewards efficiency and punishes underestimation. Pricing by outcome, such as a fixed fee for a delivered report, moves risk onto you and works best with a tight scope. Many independent workers mix the two: a fixed price for a defined first phase, followed by an hourly rate for changes or a retainer for ongoing maintenance. The right mix depends on how well the work is understood. The less certain the scope, the less sense a fixed price for the whole project makes.

Price the uncertainty explicitly. A discovery phase, paid at a fixed amount, lets both sides see what the data looks like before committing to the rest. That phase often saves more than it costs, and it gives the client a visible first deliverable.

Say no without damaging the relationship

Saying no is part of the work. Decline requests that fall outside the scope, depend on data you have not seen, or would require claims you cannot support. Do it in writing, briefly and warmly. A useful pattern is to acknowledge the request, state what is currently in scope, offer the change as a separate piece of work with its own estimate, and ask which the client prefers. The client keeps control of the decision, and you keep the boundary.

Some requests should be declined outright. If a client wants an output used to make decisions about people with no review, or wants results presented as more certain than they are, the job is not one to take at any price. Decide that before the first meeting, not halfway through the project.

Keep experiments inside a boundary

Experimentation is valuable and easy to let run on. Give each experiment a time limit, a question it must answer and a rule for stopping. A two-week test of a retrieval approach that ends with a written result, whether it worked or not, is more useful to a client than an open-ended search for the best model. Record what was tried, including the failures, so the client can see what the fee bought.

Requirements will change. When they do, check whether the change alters the scope, the timeline or the definition of done. If it does, update the document and agree on new terms before the work continues. A short written change note, confirmed by email, is usually enough.

Plan the handover before the work ends. Decide who owns the code, the data and any trained artifacts after delivery, and write it into the contract. Clients often assume they own everything, while the work may depend on a licensed dataset or a model they cannot run without a separate agreement. Naming those dependencies at the start avoids a dispute at the end.

Practice on a real request

Take a project you have completed, or one you are considering, and write its scope document on a single page. Include the inputs, outputs, exclusions, definition of done, revision rules and the first phase you would propose. Then give it to someone who has bought similar work and ask what they would cut. Their answer shows where your boundary is weakest. Revise until the exclusions are as clear as the inclusions, because that is where independent work most often goes wrong.