The problem, named directly
Clients are drowning in proposals that all sound the same. Most of them are AI-generated or AI-assisted, and they've converged on the same structure: a generic self-introduction, a list of skills, a vague claim that you can help, and a call to "discuss further." A client reading their tenth one of these in a row stops reading around the second sentence.
This isn't a reason to avoid AI tools when drafting — it's a reason to make sure what you send doesn't read like everyone else's output. The proposals that win aren't necessarily the most polished. They're the ones that prove, in the first two sentences, that a human actually read the brief.
What actually gets read
Open with the brief, not with yourself
The single most common tell of a templated proposal is starting with "I am a full-stack developer with X years of experience." A client doesn't need your resume in sentence one — they need evidence you understood their problem. Open with the specific thing they described:
❌ "Hi, I'm a experienced developer specializing in web applications with over 5 years of experience in React, Node.js..."
✅ "The 500 error after Stripe checkout is almost certainly a webhook signature mismatch — if your STRIPE_WEBHOOK_SECRET doesn't match the endpoint you registered in the Stripe dashboard, the handler silently fails and the order never gets marked paid."
The second one proves you read the post before you started typing. That's worth more than any credential line.
Reference something only someone who read the brief would know
If the job post mentions a specific stack, error message, or constraint, use it by name. Generic proposals talk about "your project." Specific ones talk about "the Supabase RLS issue on the users table." This is the cheapest, highest-leverage thing you can do, and it's exactly the thing a copy-pasted template can't fake.
Quantify relevant results, not a service list
"I have built many apps" tells a client nothing they can act on. "I fixed the identical Bolt.new + Supabase auth redirect loop for another client last month — took about 3 hours" tells them you've solved this specific problem before. If you don't have a directly relevant past job, it's fine — say what you'd check first and why, which proves technical judgment even without a matching case study.
Propose a first step, not just availability
"I'm available and can start right away" is true of almost every proposal a client receives. A concrete first step is not:
"I'd start by reproducing the OAuth redirect issue locally, then check whether the callback URL registered with your OAuth provider matches your production domain — that's the most common cause of this exact symptom."
This does two things: it shows real diagnostic thinking, and it gives the client something to say yes or no to, rather than a vague promise to "figure it out."
Keep it short
Three tight paragraphs beat one long one. A client scanning ten proposals in a sitting will read a short, sharp one in full and skim a long one for keywords. Say the specific thing, back it briefly, propose the first step, stop.
What to avoid
- Generic openers — "I am excited about this opportunity" tells the client nothing and delays the part they actually care about.
- Skill lists with no connection to the brief — if it's not relevant to this job, it's noise.
- Over-promising timelines — a confident-sounding fast estimate that turns out wrong costs you more trust than a realistic one.
- Copy-pasting the same opening across jobs — clients compare notes less than you'd think, but a proposal that clearly wasn't written for their specific post reads as low-effort even on its own.
The pattern, compressed
- Open with something specific to their brief — proves you read it.
- One line of relevant proof — a similar problem you've solved, or clear diagnostic reasoning if you haven't.
- One concrete first step.
- Stop.
That's it. It's short enough to write in five minutes and specific enough that no template could have produced it — which is exactly why it gets read.