How to Write Estimates That Clients Actually Approve (With Examples)

Writing estimates is one of those things nobody teaches you when you learn to code.

You know how to build the thing. You know roughly how long it’ll take. But turning that into a number the client can say yes to? That’s a different skill entirely.

Most developers get this wrong in one of three ways: the estimate is too vague (“it’ll be around £500”), too technical (“8 hours for API integration and endpoint refactoring”), or too long (a three-page PDF that the client won’t read past page one).

Here’s what actually works.

Why estimates get rejected (or ignored)

Before we look at how to write better estimates, it’s worth understanding why they stall.

The client doesn’t understand what they’re paying for. If your estimate says “refactor contact form handling and update validation logic,” the client has no idea what that means. They see jargon and a number. That’s uncomfortable. When people are uncomfortable, they delay.

There’s no clear scope. “Website updates: approximately £800” tells the client nothing about what’s included, what’s not, and how you arrived at that number. Without a clear boundary, the client is nervous about what they’re agreeing to.

The estimate arrives too late. If you take three days to send an estimate for a simple request, the client has already moved on emotionally. They asked in a moment of motivation. By the time your estimate arrives, the urgency has faded.

There’s no easy way to approve it. If the client has to reply to an email with “yes, go ahead,” that reply can get buried, lost, or disputed later. If the approval process is clunky, people put it off.

The anatomy of an estimate that works

A good estimate has five parts. That’s it. You don’t need a PDF template or a proposal tool. You need these five things, clearly presented.

1. What you’re going to do (in their language)

Describe the work in terms the client understands. Not what you’re building, but what they’ll get.

Bad: “Implement responsive carousel component with lazy loading and Lighthouse optimisation.”

Good: “Add an image gallery to your homepage that automatically adjusts for mobile and loads quickly.”

The first one makes sense to developers. The second one makes sense to the person paying the invoice. Write for the person paying the invoice.

2. The price

Be specific. “Around £500” creates uncertainty. “£500” creates clarity. If you genuinely can’t pin it down, give a range with a ceiling: “Between £400 and £600, and I’ll let you know before going over £500.”

Clients appreciate certainty more than cheapness. A clear number they can budget for is better than a vague number that might change.

3. How long it’ll take

Not how many hours of development. How long until they’ll see the result.

“This will take about 4 hours of development” means nothing to a client. They don’t know if that means today or next month.

“I can have this done by Friday” means everything. That’s a date they can put in their calendar and plan around.

Include both if you want: “About 4 hours of development. I’ll have it live by Friday.”

4. What’s included (and what’s not)

This is where most estimates fall short. If you don’t define the boundary, the client will assume everything is included.

You don’t need a contract-level list of exclusions. A single sentence is often enough: “This covers the gallery on the homepage. If you want it on other pages later, we can quote for that separately.”

That one line has saved me from scope conversations more times than I can count.

5. A clear way to approve it

The easier it is for the client to say yes, the faster they’ll say yes.

In an email, this often looks like: “If this works for you, just reply ‘approved’ and I’ll get started.” That’s fine, but the approval lives in a reply chain and can be hard to find later.

Better: a system where the client clicks an “approve” button and the approval is timestamped and attached to the request. That way there’s never a question about whether it was agreed.

Examples: bad vs good

Example 1: Website change

Bad estimate:

Hi, the changes you mentioned will probably take a few hours. I’d say around £300-400. Let me know if you want to go ahead.

Why it’s bad: No clear scope. Vague pricing. “The changes you mentioned” assumes the client remembers exactly what was discussed. “Probably a few hours” doesn’t give them a delivery date.

Good estimate:

Here’s the breakdown for the homepage updates:

What’s included: - Replace the hero image with the new photo you sent - Update the opening paragraph with the copy from your brief - Add the testimonials section below the services grid

Price: £350

Timeline: Done by end of day Thursday

Not included: Any changes to other pages. Happy to quote separately if needed.

Hit approve and I’ll get started.

Why it works: Clear scope. Fixed price. Specific delivery date. Defined boundary. Easy approval.

Example 2: Bug fix

Bad estimate:

I’ve had a look at the form issue. It’s a validation problem on the backend. Should be a quick fix. No charge.

Why it’s bad: “No charge” sounds generous but creates a precedent. And “quick fix” is relative. And there’s no record of what was done.

Good estimate:

Fix contact form submission error

The form is failing because of a validation issue on the server side. I’ll fix the validation rules and test across all form fields.

Price: Included in your retainer (approx 30 mins)

Timeline: Done today

I’m logging this so we both have a record of the work.

Why it works: Even though it’s free, the work is visible. The client can see it was done. And you have a record that contributes to the picture of how much work the retainer actually covers.

Speed matters more than polish

The biggest improvement most developers can make isn’t writing better estimates. It’s writing them faster.

A simple estimate sent within two hours of a request will outperform a detailed proposal sent three days later. The client is most engaged when they first ask for something. That’s the moment to get the estimate in front of them.

This is why I estimate everything from my dashboard rather than in email. When a new request comes in, I can read it, type a price, add a note, and send the estimate in under a minute. The client gets a notification, sees the price, and approves or asks questions.

The whole loop can happen in the same day. Sometimes in the same hour. That’s the kind of responsiveness that keeps clients happy and keeps your pipeline moving.

The paper trail pays for itself

Every estimate you send is a deposit in your “accountability account.” When you can show a client a list of every request, every estimate, and every approval from the last six months, you’ve built a level of professionalism that most freelancers can’t match.

It also makes invoicing painless. At the end of the month, you look at the approved estimates, add up the numbers, and send the invoice. No more trying to remember what you did or digging through emails to justify line items.

Write clear estimates. Send them quickly. Make them easy to approve. Everything else follows.

With TaskClarity, you add estimates directly to client requests and they approve with a single click. Every approval is timestamped and attached to the task. No more hunting through email threads to find out what was agreed.