Ramblings of an old-school software developer, father, and woodworker.

Recent Posts

Bidding a Freelance Contract
Thoughts on how to bid your freelance contracts.

Ninjas and Landmines
A retelling of a classic anecdote

Are Static Types Useless
Static types means more than number vs. string.

Contract Negotiations
As a software freelancer, how should contract negotiations look?

Bidding a Freelance Contract

· by Tim Mensch · Read in about 9 min · (1898 Words)
blog consulting developer post programming freelance

Asking For Money

I’ve talked some about contract negotiations and what to put into a freelance contract, but that’s not a problem until after you’ve convinced someone to pay you a reasonable amount of money to solve a problem they have.

So how do you come up with the correct amount of money to ask? This is a tricky question.

Calculating the Estimate or Fixed Bid

It takes some time to come up with a good estimate for how long a project will take. Most clients will want some form of estimate, and some clients will demand a fixed bid. I’m going to talk about my approach to creating both full estimates and fixed bids below.

What I describe may look like I’m building in a huge time buffer. For fixed bid projects, a time buffer is critical. When offering a fixed bid you’re taking a risk, and the client is buying insurance. The client wants to be certain that their costs are contained, and you want to minimize your own risk, though no matter what you’re taking on some risk, and additional risk needs to be paired with additional reward.

There is a related article by Erik Bernhardsson on Why Software Projects Take Longer Than You Think, which goes into the statistical models of why estimation is so hard. The short summary is that, when we estimate a task, we’re actually pretty good at estimating the median time to complete the task, but outliers pull up the average time to a point where we end up blowing past our otherwise reasonable schedule. The highest risk items frequently end up dominating the schedule, in fact. But I generally find my approach below to be effective, and I haven’t blown more than 10% past a schedule I’ve made in years.

As a result of the above trick of statistics, possibly combined with a bit of over-optimistic estimation, I’ve heard dozens of stories of developers who offered a fixed bid on a project only to discover that the number of hours the project actually required meant their fixed bid had pushed their hourly rate below minimum wage. In the more distant past I’ve even been there myself. Don’t bid too low or you’ll end up in the same situation.

Be Wary of Fixed Bids!

Before I start: If you’re considering a fixed bid project, then step zero is to nail down the requirements very clearly. You need to have zero question about what it is you’re doing. Think of this as a programming or logic problem: You need to handle all of the corner cases, clarify any phrase that could possibly be interpreted in multiple ways, and ensure that there are no open-ended requirements. Your fixed bid scope needs to be bullet-proof; a malicious genie shouldn’t be able to bend the words to turn your wish into a nightmare.

If you don’t have much experience writing contracts, you should ask an attorney to specifically talk with you about your “Statement of Work”–the list of tasks you’re promising to complete–with an eye to constraining and clarifying the requests as much as possible. Ask for this explicitly, or they may assume you know what you’re doing with respect to your domain of expertise. It’s by far the most critical part of your contract for most engagements; the rest of the contract is almost entirely there to help you in case there’s a lawsuit. (Of course your attorney should review the entire contract, but I talk more about that elsewhere).

How to Estimate

From what I’ve read, and what I’ve experienced, the best approach is to compare the current project to something you’ve worked on in the past. Don’t try to dig down to the details and estimate how long each part will take. Look at the overall project and compare it to how long a similar project took to complete.

Do compare the overall scope. Look at how many pages the new project has compared to the old, for instance, and let that be part of your calculus. But don’t try to calculate based on how many specific components you need to create and how many hours each should take to complete – unless the sheer quantity of components means that your time estimate for that portion of the project would actually be longer than the rough estimate. In my experience, though, when you try to dig into the details, the estimate ends up shorter than the gestalt estimate, and it’s usually because there are details that are easy to forget.

Take your similar project time period, scale it up by any relevant delta in scope, and then double its schedule. If you’ve never completed a similar project, then pick the closest example you can come up with, and depending on how close it is, multiply its schedule by a higher factor. There is some level of judgment here, and depending on how many additional unknowns in the new project, the scale could be anywhere from 2.5-4x. Beyond that it’s probably better to not use a fixed bid at all, but you can still come up with a rough estimate.

That’s your first order estimate of how long it might take. What you do with that depends on whether you want to take a risk on fixed bid or you’d rather be more conservative and work an hourly or weekly rate. If you really don’t have anything to compare, then I’d recommend you bid at a decent hourly rate instead.

Fixed Bid

If you want to offer a fixed bid, then multiply your first order estimate by what you would consider a high hourly rate. A rate that you’d be comfortable letting slip. If you want to make at least $60/hour, then multiply by $100/hour. If you want $100/hour, multiply by $150. Your specific skills, experience, and the nature of the task you’re completing will all contribute to your calculation.

The result of that calculation is your fixed bid offer. If you calculated above that the project might take 200 hours, and you want to make at least $60/hour, you multiply by $100/hour and get \$20,000 as a fixed bid for the project.


Fixed bid payments shouldn’t be requested as a single lump sum, by the way, unless the project is truly small (only a few days or less). You don’t want the client to have that much leverage. You want to structure the project into milestones that should occur no less frequently than every couple of weeks with payments after each one, and ideally you should ask for a “start-up” payment (especially if you haven’t worked for the client before), so that if they end up sitting on a later payment, at least you’ll have some compensation for your initial work.

It is fair to the client to have a slightly larger final milestone/completion payment. Clients feel better knowing they have some leverage over you to complete the project they’re paying for, after all.

Change Requests, AKA Scope Creep

I hope you’ve followed my suggestion above to nail down the requirements very clearly. If you have, and they ask you to make a change that deviates from the requirements, then it comes down to a judgment call:

  1. If the change request won’t take much more time, I recommend you just do it. I always try to keep the client happy, even if they missed some key requirement, and there is some buffer of time built into the estimate after all. Let them use it.

  2. If the change request really will cause a material change to the schedule and/or effort required, then politely let them know that it will require an official change request. If possible, tell them what other features would be roughly equivalent in implementation time, so that if they actually Really Really Need this new request, they can just trade it for one of the other (yet-to-be-implemented) features. Or tell them how much more it will cost to add that change to the fixed bid specification.

Sometimes, though, you will underestimate the effort required to actually complete a requirement you previously agreed to. Well, tough. That’s what the buffer is for, and you’ll be getting a lower hourly rate for the entire project as a result of your mistaken estimate. If you followed my other estimation recommendations, though, you should still be making a decent wage overall.

Hourly or Weekly Rate

If you want to take the “safer” route, and your client isn’t demanding a fixed bid, then tell them your hourly rate (based on industry, skills, local market, and experience) and give them an estimated range of hours centered around two thirds the above number of hours you’ve calculated – the first order calculation is designed to be very conservative, so your actual time should be less than that estimate, but it’s still an estimate.

A better approach, if you can manage it, is to bid by weekly cost, where you multiply your hourly rate by a reasonable number of hours per week. This requires a certain amount of trust on the part of the client, since the number of hours you put in will in fact be variable based on need, but at the same time it’s a more consistent expense for them. And it can be better for you, as otherwise there can be lean weeks where your income can drop off unpredictably if the workload is variable.

Money Discussions are Hard

And yes, any discussion about money can feel really hard. It’s best to treat the discussions as matter-of-fact as possible, and be ready if they ask for you to divulge exactly how you calculated your bid or estimate–to me, at least, it seems reasonable that your estimate is based on how long a similar project took to complete.

If they do ask for bid adjustments, it depends on how flexible you are on your hourly rate requirements as to whether you negotiate outright or stand firm. If you’re willing to accept a lower hourly rate, telling them you’d be willing to offer a new-client discount to help them to get to know your skill is perfectly fine, and it leaves open the option to charge higher rates later.

Another option, at least for a fixed-bid negotiation, is to negotiate over scope. If there’s a particularly high risk item in their scope, you could offer an initial phase of the project that excludes that item, and offer them a reduced bid (because of your reduced risk) along with an offer to do additional research on the risky feature to help reduce your perceived risk. In the case of an hourly or weekly contract, you could offer a wider total time estimate with an explanation that the risky feature will be harder to nail down to a specific number of hours until you’ve done more research.

Clients can be perfectly happy with honest discussion about risks. You’re an expert in your domain, and sometimes you need to step out of your domain to achieve all of the client’s goals. It’s best to be fully honest with your clients about your limitations as well as your strengths, and as long as you explain how you will be able to solve their problems, they’re usually content.

And clients who aren’t content with the truth are often the one’s you’d probably be better off firing in any case.