Prompt Engineering for Client Work

What you will be able to do: The learner can explain, with a concrete example, why a prompt that works once in a chat window is not a deliverable, and can identify the exact points where a one-off prompt will break for a client.

The problem: it worked in the chat window, so you shipped it

You typed a prompt, ChatGPT gave a great answer, and you sent that answer to your client or dropped the prompt into a Notion doc labeled "done." Two weeks later the client runs it themselves, or feeds it slightly different input, and the output is garbage. Now you look unreliable, not skilled. This is the single most common failure mode for anyone trying to get paid for prompting: treating a lucky result as a finished product.

A one-off prompt is a decision you made once, in your head, for one specific input, on one specific day. Nothing about that decision is written down, tested, or protected against change. Client work is the opposite of that: it has to survive you being asleep, on vacation, or fired.

Worked example: the product description prompt

Say a client sells electronics and asks you to help write product descriptions from spec sheets. You test this prompt in ChatGPT (free tier, GPT-4o mini, or Plus at roughly $20/month for GPT-4o):

Write a fun, engaging product description for a wireless mouse
with these specs: 2.4GHz, 6 buttons, 1600 DPI, USB-C rechargeable, black.

The output is genuinely good. Punchy, on-brand, three short paragraphs. You hand it over. The client is happy. Then, next week, three things happen that you didn't plan for:

• They send specs for a keyboard, not a mouse, and the specs arrive in a different order (color first, then connectivity, then price).
• A junior staff member runs the same prompt but forgets to include the word "fun," so the tone drifts flat and corporate.
• They need the same description in French for a second storefront, and the prompt has no instruction for that.

The prompt didn't fail because it was badly written. It failed because it was never built to handle variation. It encoded one input shape, one tone assumption, one language, and none of that was visible or adjustable to anyone but you, on the day you wrote it.

What actually breaks, specifically

One-off prompts fail along four predictable seams:

• Input shape. The prompt assumes data arrives in a specific order or format. Change the order, and quality drops without warning.
• Missing constraints. Tone, length, banned words, reading level — if these live only in your memory, nobody else can reproduce them, including future you in three months.
• No error handling. What happens when a spec field is blank, or the input is in the wrong language, or there are ten items instead of one? A one-off prompt was never tested against these cases, so it just guesses.
• No handoff. If the client's team runs it without you, there's no documentation telling them what "good output" looks like versus "something went wrong."

What a repeatable version looks like instead

The fix is not a smarter single prompt. It's turning the prompt into a small system: a fixed instruction block, a clearly labeled place for variable input, explicit constraints written out instead of implied, and a short list of edge cases you've actually tested (empty field, extra-long input, wrong language). That system gets a name, a version number, and a place to live outside the chat window — which is exactly what later lessons in this course build toward.

Concretely, the same mouse prompt becomes something like:

ROLE: You write product descriptions for [Client Name]'s online store.
TONE: Upbeat, concise, no jargon. Never exceed 3 short paragraphs.
INPUT: A list of specs in any order, any language.
RULES:
- If a spec field is missing, omit it silently. Do not mention it's missing.
- Detect the input language and reply in that language.
- Always end with one short call-to-action sentence.

SPECS:
{{paste specs here}}

This version survives a new staff member running it, a French input, and a spec sheet with a missing field. That's the difference between a prompt and a deliverable.

What this unlocks

Once you can see exactly where a prompt is fragile, you're ready to build prompts as reusable templates with defined inputs and outputs — which is the actual billable unit in this line of work, not the clever one-time answer.

Key points

• A one-off prompt encodes hidden assumptions about input shape, tone, and language that live only in your head.
• Prompts fail at four predictable seams: input shape changes, missing constraints, no error handling, no handoff documentation.
• Client work has to survive being run by someone else, with different input, on a day you're not there — a single chat result never does.

Practice

Take a prompt you've used before (or the mouse example above). Run it three times with deliberately varied input: one normal case, one with a missing field, one in a different language or format than you first tested. Write down, in a short table (input | output | what broke), exactly where quality or format failed. Done means you have at least one documented failure case you didn't expect before running the test.