How I Estimate Projects (Honestly)

Every estimate is a guess. The honest move is to say so. I have sat across the table, and more often across a video call, from dozens of clients who asked the same reasonable question: “How long will this take, and what will it cost?” Early in my freelance career I answered with a single confident number, because that is what I thought a professional was supposed to do. Then I spent years watching those confident numbers slip, quietly eating my evenings and, worse, slowly eroding the trust of people who had been kind enough to hire me.

Here is how I estimate without over-promising. It is not a secret formula. It is a handful of habits, a simple spreadsheet and a willingness to have one slightly uncomfortable conversation at the start of a project instead of a very uncomfortable one at the end.

Start with the pieces

I never estimate a whole project at once. “Build a booking website for a yoga studio” is too big to guess honestly. So the first thing I do, usually in a one-hour paid discovery session, is break the work into pieces small enough that I can picture myself doing each one.

For that yoga studio, a real project I did for a studio in Boulder, Colorado, the list looked something like this: homepage, class schedule page, instructor profiles, booking flow, payment integration, confirmation emails, an admin screen to manage classes, content migration from the old site, testing on phones, and launch. Each of those became a row in my spreadsheet. Some had sub-rows. The booking flow alone had six.

Breaking work down does two useful things. It makes my guesses better, because I am comparing each piece to similar pieces I have built before. And it shows the client exactly what they are paying for, which makes later conversations about scope far easier. If the total comes in above their budget, we can look at the list together and decide what to move to a second phase, instead of arguing about a single mysterious number.

Give ranges

“Four to six weeks” is more honest than “five.” Every row in my spreadsheet gets two numbers: a likely case and a cautious case. The likely case assumes things go roughly as planned. The cautious case assumes the usual small surprises: a payment provider’s documentation is out of date, content arrives late, a design needs a second round.

When I add up the rows, I get a range for the whole project. I share that range, not the midpoint. Clients occasionally push back and ask for “just one number.” When they do, I explain that a single number is still a range, it is just a range where I am hiding the top half from them. Most people appreciate that framing once they hear it.

An honest estimate is the start of trust.

Leo

Ranges also change the tone of the project. If we finish near the low end, everyone is pleased. If we land near the high end, nobody is surprised, because we talked about it on day one. The project feels on track either way, which is the whole point.

Name the risks

I list the three things most likely to slow us down. Not ten, not a page of legal-sounding caveats. Three, in plain language, written into the proposal. For the yoga studio they were:

1. Content timing. The schedule and instructor bios had to come from the studio owner, who was also teaching nine classes a week.
2. The payment provider. The studio wanted to keep the class-pass system they already used, and its developer tools were thinly documented.
3. Design decisions by committee. Three co-owners would review every page, which is wonderful for buy-in and slow for approvals.

Naming risks does something almost magical: it turns them into shared problems. When the bios came in two weeks late, the owner, a cheerful woman named Priya Halvorsen, emailed me before I could bring it up. “I know, I know, risk number one,” she wrote. We adjusted the timeline together, and nobody felt blamed.

The buffer I don’t hide

Many developers pad their estimates in secret. They add 30 percent to every number and say nothing. I understand the instinct, but I think it backfires. Hidden padding makes estimates look arbitrary, encourages clients to negotiate them down, and leaves the developer feeling quietly dishonest.

Instead, I put the buffer on its own line. It is usually 15 to 20 percent of the total, labeled “Contingency for unknowns,” with a short sentence explaining that every project has surprises nobody can predict in advance. If we do not need it, the client does not pay for it. If we do, they can see exactly where it went.

This approach has a pleasant side effect. Clients start treating the buffer as a shared resource. On a recent project for a bakery in Savannah, Georgia, the owner asked for an extra gift-card page halfway through. Instead of a tense change-order discussion, she said, “Can we use some of the contingency for that?” and we agreed in two minutes.

Check in, and re-estimate

An estimate is not a promise carved in stone. It is my best guess with the information I had on day one. As a project goes on, I learn more, and the estimate should improve. So every Friday I send a short update with three lines: what got done, what is next, and where we stand against the range. If the range needs to move, I say so right away, with a reason.

That weekly note takes me about ten minutes. It has saved me countless hours of awkward conversations. Small, early adjustments are easy to accept. A big surprise in the last week is not.

Learning from the past

After every project, I compare my estimate to what actually happened, row by row. Over the years this has taught me some humbling lessons. I consistently underestimate content migration. I overestimate how long layout work will take. Payment integrations are always worse than they look. I use those patterns to adjust the next estimate, which is why my ranges have gotten noticeably tighter over time.

Key takeaway: a good estimate is a range, a short list of named risks and a visible buffer, revisited every week as you learn more.

What clients get out of it

I sometimes worry that all this honesty makes me look less impressive than a competitor who promises everything in exactly five weeks for exactly one price. Occasionally I do lose a project that way. But the clients who choose me tend to stay, refer their friends and come back for the next project. Priya’s studio has hired me three more times. The Savannah bakery owner sent me two new clients last spring.

If you are a client, ask your developer for a range and their top three risks. If they cannot name any, that is a risk in itself. If you are a developer, try sharing your buffer openly on your next proposal. It feels strange the first time. By the third project, it just feels like the truth, and the truth turns out to be a very good business plan.