Going freelance in AI: the decisions to settle before you start

Going freelance is usually told as a sequence of administrative steps. In practice the hard part sits elsewhere: an employee is hired for a job, a freelancer is engaged for an engagement. Those are not the same thing to prepare, nor the same thing to defend.

Selling an engagement is not applying for a job

A job application deliberately leaves room for the unknown: a company hires a person for an open-ended period, betting on their ability to learn the context. An engagement works the other way round. It is bounded, it exists for a reason, it has an expected outcome and an end date. The client is not buying potential; they are buying ownership of an identified problem.

Why very broad expertise is hard to buy

A profile claiming to cover data, machine learning, generative AI, cloud, production and change management puts the client in a difficult position. Not because it is implausible, but because the client then has to decide what to hand over — and that decision is exactly the work they were trying to outsource.

• A broad offer forces the client to invent the scope; most have neither the time nor the standing to do it.
• It makes comparison impossible: next to a specialist, a generalist reads as a « just in case » profile.
• It makes pricing awkward, because price attaches to value and value attaches to a named problem.
• It kills word of mouth: people recommend someone « for a topic », not « for AI in general ».

Narrowing does not mean refusing everything else. It means choosing the front door: one problem you are visibly legitimate on, from which other topics will naturally follow once the relationship exists.

Turning employed experience into usable evidence

An employee CV tells jobs and dates. Freelance evidence tells a situation and an ownership. The raw material is the same; the framing changes. One simple structure covers almost every experience.

1. 1

   The problem

   2 sentences

   What was going wrong, for whom, and why it became something worth addressing. Without the problem, the rest reads as a task list.

2. 2

   Your ownership

   1 sentence

   What was precisely yours, and what belonged to others. It is the part most often left vague and the part most closely examined.

3. 3

   The approach

   3 to 4 sentences

   How you went about it, in what order, under which constraints. This is where actual skill becomes visible.

4. 4

   The decisions

   2 sentences

   The trade-offs you carried and what you ruled out. An owned decision is worth more than an unexplained outcome.

5. 5

   Outcome and limits

   2 sentences

   What changed, and what was not solved. Naming a limit is what makes the rest believable.

Talking about confidential work without disclosing anything

Much of your experience may sit under an NDA or in a sensitive context. That prevents naming clients, quoting data, describing precise architectures or contractual details. It does not prevent demonstrating skill, because what you demonstrate is not the client's information — it is your reasoning.

• Replace the client name with a type and a size: « an insurer », « an e-commerce platform », « a software vendor ».
• Describe the nature of the data, never the data: « multilingual contractual documents », with no excerpt.
• Talk about the class of problem rather than the exact implementation: « document search over a heterogeneous, versioned corpus ».
• Explain the trade-offs without the artefacts: an architectural decision can be told without an internal diagram.
• Keep outcomes qualitative: what the team could do afterwards that it could not do before.
• When in doubt, ask. Many former employers will approve a generic wording in writing.

Anonymous but precise evidence convinces more than a prestigious client name followed by three vague lines. What the reader is assessing is how you think.

Framing a need and proposing a scope

The first engagement is often won before the engagement: in the ability to listen to a vague request and come back with something workable. It is the most quickly visible freelance skill, and the one an employee has rarely had to exercise alone.

1. 1

   Discovery

   first conversation

   Understand the trigger: why now, who is affected, what has already been tried. Requests phrased as solutions (« we need a chatbot ») almost always hide a different problem.

2. 2

   Qualification

   before proposing

   Check there is a decision-maker, access to data or people, and a possible definition of success. An engagement missing those three becomes unmanageable regardless of your technical level.

3. 3

   Scope and deliverables

   in writing

   State what is included, what is not, and in what form the work is handed over. A named deliverable protects the client as much as it protects you.

4. 4

   Dependencies and assumptions

   in writing

   Name what you depend on: access, environment, counterparts, pending decisions. An unwritten dependency becomes your responsibility by default.

5. 5

   Success criteria

   in writing

   How you will jointly know the engagement met its goal. On a probabilistic system this takes more explicit definition work than elsewhere.

6. 6

   Communication and out-of-scope

   from the start

   Cadence, reporting format, and what happens when a request falls outside the frame. Out-of-scope is not a conflict; it is a change request, provided it was anticipated.

Being ready does not mean knowing everything

The idea that you must be an absolute expert before going independent is both false and paralysing. Clients do not expect a freelancer to know everything; they expect them to know where they stand. What has to be solid is the clarity, not the coverage.

• What you can take on end to end, on your own.
• What you cannot take on, and would rather not sell.
• The assumptions your proposal rests on.
• The dependencies that, if they slip, change the schedule.
• The risks you can see and how you propose to reduce them.
• The point at which you would recommend bringing in a complementary skill.

Saying « this part is outside what I own; I can frame it but I would recommend someone else to execute » reads, to most clients, as professionalism. It is also what separates a lasting relationship from an engagement that ends badly.

Getting concretely ready for the first engagement

Before you even start looking, a few things deserve to exist in written form. Not for appearances, but because writing them forces you to settle questions the first client will raise anyway.

• A short statement of your positioning, understandable by a non-specialist.
• Two or three pieces of evidence written as problem, ownership, approach, decisions, outcome, limits.
• A description of how you work: cadence, availability, on-site or remote, tracking tools.
• A list of what you do not take on, ready to be said without awkwardness.
• A simple reusable proposal template covering scope, deliverables, dependencies and success criteria.

The first engagement carries a particular value: it produces your first evidence as an independent, the kind you can tell without leaning on your employed past. It is not necessarily the best paid or the most impressive one; it is the one you can defend, deliver, and then talk about.

• Freelance
• Scoping
• Positioning