Web developer proposal template (for real client posts)

This template is for job posts where the client wants a build, a fix, a migration, or an integration. It focuses on scope control and unknowns, because that is where dev projects explode after you are hired.

Use it when you have enough post detail to infer stack and outcome; pair it with how to write a strong proposal when the job post is basically empty when the brief is thin. For platform-agnostic patterns, freelance proposal examples complements this page.

When this template fits

• Greenfield sites or apps with a described stack or reference product.
• Bug fixes or performance work with a URL or repo mentioned.
• API integrations, auth, payments, or CMS work with named tools.
• “Take over this codebase” posts: then emphasize discovery and guardrails.

Full copy-ready template

Hi [Name],

You are looking for [deliverable] on [site/app/project name if given] using [stack or platform from their post, or your default if they said “open to suggestions”].

I have shipped similar work: [1-2 specifics: performance win, tricky integration, scale, accessibility, or migration complexity].

What I understood as in-scope

• [Bullet: user-facing outcome or feature]
• [Bullet: technical requirement they named]
• [Bullet: delivery format: e.g. responsive, admin panel, API endpoint]

Out of scope / needs confirmation

• [Bullet: e.g. content creation, design from scratch, DevOps on their infra]
• [Bullet: e.g. third-party approvals, legal review, app store submission]
• [Bullet: anything that depends on access you do not have yet]

Plan

1. Discovery: confirm [requirements] and access ([repo, hosting, analytics, staging, VPN]).
2. Implementation: [feature breakdown in 1-2 lines] with incremental commits / preview deploys if applicable.
3. QA: [devices, browsers, test types, or smoke checklist]; note any known limitations.
4. Handoff: README or deployment notes + short Loom if useful; knowledge transfer window [X days or sessions].

Timeline: [X]
Cost: [fixed / range / hourly with estimate]. Assumes [key assumption]; changes if [scope lever] changes.

If anything above is wrong, tell me what to adjust and I will revise quickly.

Best,
[Your name]

Section-by-section notes (so you do not sound generic)

Opening: Mirror their outcome and stack exactly as they wrote it. If they were vague, say your working assumption in one line.

In-scope: Three bullets max in the first message. You can attach a fuller spec after they reply.

Out of scope: This is where senior devs win trust. Clients rarely punish you for listing unknowns. They punish surprises after payment.

Plan: Numbered steps signal you have done this before. “Discovery” protects you on inherited codebases.

QA: Even a single line (“latest Chrome/Safari, mobile 375px, smoke on checkout”) beats “I test everything.”

Variations

Legacy / unknown codebase

Add after Out of scope:

First milestone is a read-only audit ([timebox]) to confirm estimates; if the code diverges from the post, I will revise timeline and cost before heavy build work.

Fixed-price vs hourly

• Fixed: Tie price to a named milestone list; state one free revision round or paid change requests.
• Hourly: Give a cap or “first X hours for Y” so they can budget mentally.

Security-sensitive work

Mention no production credentials in chat, NDA OK, staging-only first, whatever matches your real process.

Why clients respond

You show engineering judgment: you separate unknowns, define a plan, and make the next step obvious, without five paragraphs of stack flexing.

Pitfalls to avoid

• Dumping every technology you have ever used.
• Promising deadlines before you have repo access.
• Hiding behind “let’s jump on a call” with zero written plan.
• Quoting without naming what happens if scope creeps.

If you want this adapted to an actual post, paste the job text into Lervos and let it map requirements to your real experience.