Research only enough to understand the job
Before writing, state the client’s problem, the outcome, the risk, and the evidence you can offer. If the post does not contain enough detail, decide whether one useful question can close the gap.
Do not invent personal facts from a company page or fill the opening with copied praise. Relevant attention feels personal because it names the work, not because it pretends you know the buyer.
- What is wrong or unfinished?
- What should change?
- Which proof is closest?
- What is one safe first step?
Use the five-part proposal shape
A practical proposal has five parts: a specific job detail, the problem in plain words, the closest proof, a sensible first step, and one easy question. One or two lines per part is often enough.
This is a shape, not a script. Remove a part when the job makes it unnecessary. Keep the facts true and make the voice sound like you.
- 1. Specific detail from this job.
- 2. The problem or outcome in plain words.
- 3. One matching proof point.
- 4. A small first step or useful thought.
- 5. One question that moves the work forward.
Open with the work, not a copied greeting
The client can already see your name and profile. Use the first line to show what you noticed. Avoid ‘Dear hiring manager’, ‘I am the perfect candidate’, or a long list of years and tools before the job appears.
A direct opening can still be warm. The difference is that it gives the client useful information immediately.
‘The mobile comparison table is the part I would fix first. Users need the key values without dragging the whole page sideways.’
Use proof with role and context
The strongest proof is close to the current problem and clear about your part. Use a four-step line: situation, your role, the change, and the honest outcome. Do not borrow the whole team’s result.
A number is not required. A shipped feature, a repaired workflow, or an approved decision can be useful proof when it is specific and true.
‘On a recent dashboard project, I owned the responsive table and filter work. I changed the dense desktop grid into focused mobile rows while keeping the same API and permissions.’
Offer a first step without doing free work
A small plan shows how you think. It should not become an unpaid version of the project. Name what you would inspect, the first decision, or the smallest useful milestone.
For a large job, explain the first checkpoint and what it would clarify. This helps the client discuss scope without receiving a full solution for free.
- Name the first thing to check.
- State one assumption or risk.
- Suggest a small paid milestone when appropriate.
- Keep private methods and large deliverables out of the free pitch.
Handle price and timing with honest assumptions
Answer the budget or time question when the scope supports an answer. When it does not, name the missing fact and give a range only if you can explain what changes it.
Do not promise a launch date before checking dependencies, access, feedback, and the work already in place. A careful boundary builds more trust than a fast guess.
‘If the current API already returns the three mobile fields, I can handle the table change as one milestone. If the API also needs work, I would confirm that scope after a short code review.’
See the complete five-part example
This fictional example is here to show the structure. It is not a real UGD proposal or client result.
The mobile comparison table is the part I would fix first. Users need the key numbers without dragging the whole page sideways. On a recent React dashboard, I owned the responsive table and filters, changing a dense grid into focused mobile rows while keeping the same API. I would first map the three fields mobile users need, then build one working row before changing the full table. Do mobile users need every column, or only the key three?
Edit before you send
Read the proposal once as the client. Can they find the problem, proof, first step, and question without searching? Remove a sentence when it only repeats your profile or praises you.
AI can help organize a draft, but it cannot verify your experience or know what happened on a private project. Check every claim, remove generic wording, and rewrite the final version in your voice.
- One client and one real problem.
- One proof point with your role.
- No invented result or fake familiarity.
- No filler, password request, or rule-breaking contact detail.
- One useful question and a human final read.
Clear answers before you act.
How long should an Upwork proposal be?+
There is no fixed ideal length. Use enough space to show understanding, matching proof, a sensible first step, and one question. Remove anything that does not help the decision.
Should I start with ‘Dear client’?+
You can greet the client, but do not let a generic greeting use the strongest opening space. A specific observation about the job is usually more useful.
Should I include a price?+
Include a price or range when the scope supports it and the client asks. Name important assumptions instead of pretending an unclear project has a precise price.
Can I use AI to write a proposal?+
Use it as a drafting helper only if you verify every fact, protect private information, and rewrite the final copy in your own voice. Never let it invent proof.
How many work samples should I link?+
Usually one or two close examples are easier to judge than a large list. Explain why each sample is relevant and what part was yours.
Check the source, not just our word.
Platform details can change. This guide was reviewed on September 18, 2026. If something looks wrong, email team@upgrowthdesk.com.