Fixed Price Contracts and Freelancing

I’ve been using fixed price contracts almost exclusively since I started freelancing in 2008. If you’re not familiar with the term, a fixed price contract is a contract where the amount of payment depends on producing some deliverable and does not take into account the time taken or resources expended to produce that deliverable. This is in contrast to a time-based contract where the client pays for every unit of time spent on their project, or a cost-plus contract where the client agrees to pay for the contractor’s costs plus some predefined profit margin.

Fixed price contracts appeal to prospective clients for a number of important reasons:

  1. Most of the risk of the project is shifted from the client to the contractor
  2. The client knows upfront exactly how much they will pay to receive what is specified
  3. There is very little administrative burden for the client – they don’t have to review time sheets or address itemized expenses

What’s In It for Freelancers?

While the benefits of fixed price contracts for freelancers are a bit more nuanced than the benefits for clients, I believe they are worth it.

More Money

You’ll make more money with fixed price contracts by taking advantage of value-based pricing. Value-based pricing means you charge the amount that your work is worth to your client, not the amount it costs you to produce it. This is a game-changer if implemented correctly.

An example is easy to come by. Recently, a prospect approached me and asked if I could fix some issues on their website for them. They obviously needed it done in short order and it was apparent that the issues were hampering their ability to run their business the way they wanted to.

I proposed an amount I thought would be acceptable to them based on their circumstances (it was in the low four figures), it was accepted, and I went ahead with the work. It took me a total of two hours to finish.

The client was super happy their problems had been resolved so quickly and I made a ton of money for my time. That’s the best possible outcome for any project.

Cash Flow

Fixed price contracts lead to a better understanding of your cash flow. This is a really good thing – one of the scariest parts of freelancing is the uncertainty of not knowing when money is going to come in.

For example, you set the price for a particular project at $5,000. Assuming a 40% deposit, you’ll receive $2,000 at the start of the project and $3,000 when it is over. If you stay on schedule for the project, you’ll have a really good idea of when you’ll receive that money. This knowledge allows you to schedule the rest of your work so that you have the money you need when you need it.


One of the big dangers of freelancing is losing motivation to work on a project. In my experience, this is much more likely to happen with an hourly project where you’re unsure of the end then a well-specified fixed price contract where you know you’ve delivered the appropriate items and are going to get paid.

Things To Look Out For

Fixed price contracts aren’t always rosy. There’s a number of situations where they’re going to cause more trouble then they’re worth.

Ambiguous Project Definitions

This is an issue that has bit me (and other freelancers that I’ve talked to) more than any other. You start a project, build something you think the client is going to love based on the documentation you’ve received or produced, and then you deliver. Great! You’re done and getting ready to move on to the next project when your client sends you an email.

Wait, the client says, where is Feature X, Page Y, and instruction Z? You go back and try to explain that those things obviously weren’t part of the project (they’re going to take you 15 hours each, you’re thinking) until you look over your statement of work. That’s when you spot it – an ambiguous paragraph or sentence that could have led the client to believe that what they are asking for was included.

Now you’re stuck. You can either provide what they want, lose money and sleep, and get on with your life or you can put your foot down and insist that the requested items will have to be part of a separate work order. The first option makes things bad for you, the second makes things bad for the client, and this awesome project just turned into a cesspool.

If you’re going to work on fixed price contracts, you need to make sure the project is specified as well as it can be. There can’t be any questions about what is going to be built. That leads directly to the next danger.

Protracted Specification Period

If you’re going to specify a fixed price for a new project and you want to have a good experience, you need to know exactly what you’re building. This can sometimes lead to dozens of emails back and forth where you’re asking for clarifications on seemingly minute details.

While you can probably narrow down the price to a range during this process, it takes time and effort and you can’t be totally sure that your price is even going to be accepted by the prospect. Also, the prospect can get frustrated by all the back and forth and move on to another freelancer that will push forward with the project immediately.

You can mitigate this danger by charging for the specification process, but unless you have an existing point of contact or relationship with the prospect, that doesn’t always work.

Mid-Project Change Requests

Sometimes you’ll get into the middle of a project and a client changes their mind. They want to implement X instead of Y and change A to B. Sure, you say, we can do that, but I need you to specify exactly the changes you want, formalize it into a change request, and I can give you a quote on top of what we already specified.

These conversations are hard. They’re even harder when you have X half-built and the client can’t see it, but wants to swap it out for Y. It can be hard to explain that, while there isn’t a visible component of feature X, you spent time on it and will need to charge the complete price of switching to Y even though they never saw X.

I haven’t found a good way to deal with these things that makes everyone happy. If you’ve found something, I’d love to hear it.

What Do You Think?

I’ve tried to make the benefits of fixed price contracts clear in this post. I’ve had great success with them and I know others have as well. What about you? Do you use fixed price contracts and how have you dealt with some of the dangers involved? Have you encountered other things that make you shy away from fixed price projects? If you use another billing method, I’d love to hear about it in the comments below.

4 thoughts on “Fixed Price Contracts and Freelancing

  1. Dan Cameron

    Yep, right on.

    I have a process where we get contracts based on flat rates, then start billing hourly for any additional features/updates if it leads to a longer term project. That’s only if we end up doing minor updates/development and not do a “second phase”.

    1. Nick Ohrn Post author

      That’s a good strategy, Dan, and something that I try to take advantage of.

      When someone wants to do something like that, I’ll ask myself if it is going to take longer than 8 hours. If it is, than it should be a new project. If not, let’s just tack it on.

  2. Brian McNitt

    From an agency perspective, working with subcontractors to deliver client work, all of the benefits of the fixed price model apply as well, but things break down when the small “hourly” requests come in, and they always come.

    Sometimes if the requests are not urgent you can group enough of them together (i.e. – 8+ hours) and develop another scope of work. But this usually doesn’t match client needs — something needs to happen today or tomorrow and it should only take an hour or less to fix — it’s a reasonable request, and it just shouldn’t cost much. But, as an agency, we need to field the request, contact the developer, often sweet talk the developer so it gets done and make sure the client is happy. When it comes to invoicing, we have one hour from the developer to cover plus our overhead and the price is a lot more than it should be. It’s a lose, lose, lose situation.

    It’s a loss for the developer because it’s expensive to do an hour of work here and there, it’s a loss for the agency for the same reason plus there’s usually zero profit in it, and it’s a loss for the client because they often feel the resistance from the developer and agency — something you absolutely don’t want the client to experience as a service based business — and the resulting agency bill is always too high for the small bit of work.

    So what’s the solution here?

    One thought I’ve had is to start thinking and communicating with clients in terms of “releases”. If project X.0 is a website build, then from the very beginning we start to define release X.1, X.2 and so on to capture all of the smaller, non-urgent requests that come up. Surely there will always be hot fixes needed (i.e. X.1.1), but perhaps promoting release based work would be a start. Thoughts?

    1. Nick Ohrn Post author

      Brian, all really good points and I’m not sure if there is any single answer.

      In an ideal world, you’d be on retainer so you’d have a guaranteed number of hours for a particular client, likely scheduled on consecutive days (maybe Monday-Tuesday, middle of the month) and you’d work with your client to gather requirements before their “timeslot” and then do what they needed then. If the work was going to be more consistent, you’d allot them multiple slots.

      I think this goes along with your idea of releases. You put everything into a bucket to start with and then build the releases out of there. You then commit to doing a release every so often depending on the client’s rate of change and budget.

      Neither one of these deals with the other scenario that you’ve outlined, though, where it is a relatively small thing that could be handled in an hour. I’m not sure what the answer is there other than “We don’t work that way, let’s slot it in the next release.” or “This needs to be taken care of in-house if it is urgent.” If you made the releases weekly (and the client was willing to pay for 5-8 of developer / PM time a week) that would be often enough to take care of those things without any problems. Of course, that costs some money and is probably not viable for all but the least price-conscious clients.


Leave a Reply

Your email address will not be published. Required fields are marked *