The Claude Prompt That Saved My Freelance Career. And the One That Nearly Ended It.

I used both in the same month. I only talk about the first one at parties.

Claude · Freelance Development · Client Communication · Automation

I want to tell you about the best month of my freelance career. And the worst week of it. They happened within three weeks of each other.

Both involved Claude. One I credit with changing my career trajectory. The other I think about every time I write a script that touches client data.

STORY ONE: The Proposal

In October I got on a discovery call with a Series B startup that needed a complete data pipeline rebuild. Six-figure contract. Three other developers pitching.

My previous proposals were detailed technical documents — stack choices, architecture decisions, implementation timelines. Written entirely for me and not at all for the people reading them.

This time I described the call to Claude and asked it to help me see the proposal from the client’s perspective rather than mine. What came back changed how I write every client document.

Prompt 1 — Discovery Call to Scope Document:

Turn the following discovery call notes into
a structured project scope document.

My rough notes from the call:
[paste notes as-is — don't clean them up]

What I understood their core goal to be:
[one sentence — your interpretation]

Produce a scope document with:
1. Project Overview (2–3 sentences):
   What this achieves for the client in
   business terms, not technical terms
2. What's Included:
   Specific, concrete deliverables — each item
   something both parties can verify as done
3. What's NOT Included:
   3–5 things explicitly out of scope
4. Assumptions:
   What I'm assuming that, if wrong, would
   change the scope or timeline
5. Open Questions:
   Specific things I need before finalising

Tone: professional but plain. Nothing that
requires a technical background to understand.

The overview it wrote: “This project will give Meridian a data pipeline its analytics team can trust — one where they know what’s in it, why it’s there, and what to do when something looks wrong.”

I had written: “We will implement a robust ETL pipeline with monitoring and alerting capabilities.” Same meaning. Completely different experience for a founder reading it at 9PM.

The prompts that fixed the gap are in The Claude Developer Playbook — Order Now at $9

Prompt 2 — The Technical Proposal:

Write a client-facing technical proposal.

Project scope: [paste scope document]
Technical approach: [describe as technically
  as you want — Claude will translate]
Timeline: [duration and milestones]
Investment: [pricing structure]

Structure:
1. The Problem: their problem in their words —
   not what they asked for, the underlying issue
2. The Solution: outcomes and benefits, not
   implementation. What will they be able to
   do that they can't do now?
3. What We'll Build: deliverables for a
   non-technical reader. No acronyms unless
   explained in one sentence
4. How We'll Work Together: timeline, milestones,
   what's needed from them
5. Investment: specific. "50% upfront, 50% on
   completion" not "payment upon completion"
6. Why Me: not a CV — the specific reason I'm
   the right fit for this exact project
7. Next Steps: one specific action

Tone: confident, client-focused. The tone of
someone who has done this before and will
do it well.

The “Why Me” section: “I’ve rebuilt data pipelines for three companies at your stage — Series A to Series B, when the startup data that worked at 50 employees starts breaking at 200. I know exactly where the complexity lives in this kind of project.”

I had written: “8 years of experience, strong PostgreSQL and Airflow background.”

I won the contract. The founder told me my proposal was the only one that described the problem they actually had.

100+ prompts structured the way senior engineers actually use Claude — grab the playbook for $9

STORY TWO: The Script

Four days after winning Meridian I was doing maintenance for an existing client. Product catalogue cleanup — duplicates removed, categories normalised. I wrote a Python script, tested it against a small sample, and ran it.

I had not included a dry-run mode.

The script ran. It normalised categories correctly on the records I’d tested. On records I hadn’t tested — products with categories that matched the pattern but were intentional variant spellings the client used for their internal taxonomy — it overwrote data that couldn’t be regenerated.

Partial backup. Two hours of their team’s recovery time. A conversation I would rather not have had.

Prompt 3 — The Shell Script With Non-Negotiable Safety Requirements:

Write a production-quality script that does:
[describe the task]

Context:
- What data this touches: [describe]
- What goes wrong if it fails: [impact]

Non-negotiable requirements:
1. set -euo pipefail
2. Validate all inputs at the start —
   fail immediately with specific messages
3. Log every meaningful action with timestamp
4. DRY-RUN MODE — mandatory:
   --dry-run flag that prints exactly what
   the script would do without doing it.
   Every modifying action must be printed.
   No data modified when --dry-run is passed.
   No exceptions.
5. For data scripts:
   Show affected record count before proceeding:
   "This will modify X records. Proceed? (yes/no)"
   Require typing "yes" — not y, not Enter
6. No hardcoded values
7. Cleanup trap for temp files and partial state

After the script:
- Command to run dry-run first
- What to verify in dry-run output before
  running for real
- The most dangerous line and why

Dry-run mode on a data modification script is not a convenience feature. It is a professional obligation when touching a client’s production data.

These few are from a library of 100+ — The Claude Developer Playbook, Order Now

Prompt 4 — The Incident Communication:

Write a client communication about this incident.

What happened: [honest description]
Client impact: [their time, data, business]
What I've already done: [action taken]
Recovery plan: [what, by when]

Requirements:
1. Fact in the first sentence — not buried
   after three paragraphs of context
2. One genuine acknowledgment — not repeated
3. Client impact stated directly
4. Recovery plan specific: not "we'll resolve
   this" but "I will have this restored by X"
5. Specific process change to prevent recurrence
6. Clear next step

Tone: calm, direct, accountable. Someone who
made a mistake, owns it, and has a plan.

The message I sent opened: “During last night’s catalogue maintenance, a script I ran modified some product categories incorrectly. Here’s what happened and what I’ve done about it.”

The client replied within twenty minutes. We were discussing the next project two weeks later.

The full workflow, plus 95+ more like it — Order The Claude Developer Playbook for $9

The Lesson That Connects Both

The winning proposal failed to win until I stopped writing for myself and started writing for the client. The script failed until I designed for real data, not test data.

Both are the same mistake: designing for the ideal case instead of the real one.

Claude didn’t fix either automatically. What it did was give me a prompt structure that forced the right perspective — client outcomes in the proposal, safety requirements in the script — before I wrote a word or ran a line.

The discipline is in the prompt. The prompt is in the instruction.

The production readiness checklist I now run before every AI feature ships is in The Claude Developer Playbook — $9 at launch

Follow for the full series — practical prompts from someone who uses these tools every day.