Fixed Price Development Contracts Are Bad For Business

Author: Ben Buie Ben Buie | 7/23/15

As a freelance web developer, the first question I often get from a new client is, “Can you give me a quote for X?” This is a great question and I usually give them a ballpark figure or refer them to this article: the price of a website.

These quick estimates are great for helping them make a budget, but they’re horrible contracts. Here are a couple reasons you may want to sign an hourly contract with your next web developer:

Estimates are Always Wrong

Estimates are always wrong. Yep, I’ve never seen one that is right. Ever. And that means that in hind sight, a fixed price contract will always favor you or the developer (likely the developer).

A fixed price contract will always favor one party.

So, lets say the contract favors you in the end. In other words, the developer underestimated the hours for your project. Hooray, you get some value for nothing. Right? Maybe, but take a second to think about your future relationship.

At best, your developer may bite his/her tongue and hope for future work from you. Even so, they’re not going to be satisfied with the deal.

They’ll likely try to negotiate a change in contract. This is usually my goal, although I’ve never successfully negotiated the full value of my extra work and am always left unsatisfied.

At worst, they may choose not to work with you again. That is bad for a couple reasons: (1) You’ve (no doubt) invested (or now wasted) some budget getting them up to speed with your project and business and (2) they’re now likely the most familiar person with your project and would be the most efficient person to perform updates and maintenance (lower cost).

Truth is, it only takes one or two poor estimates by a developer before they learn to either avoid a fixed price or overestimate hours. This is why fixed price almost always favors the developer.

A fixed price contract will almost always favor the developer.

This is true not because they want to rip you off, but because of the many reasons a project can go over budget: out of scope changes, bugs with existing platform, bugs with conflicting features, bugs with niche our outdated web browsers, etc.

When they overestimate, you loose. Regardless, one party always gets a bad deal.

Sending the Wrong, Strong Message

In addition to jeopardizing a relationship with your developer, it can also jeopardize the quality of your code.

The principles of good code as I see them are (in order of importance):

  1. It works (happy client)
  2. It is well written and readable (maintainable)
  3. It is written with as few lines of code as possible (maintainable)
  4. It is on time (speed)
  5. It is under budget (price)

Some clients don’t realize that a fixed price contract moves #5 (price) well up the list in importance. The developer gets paid the same as long as it works (#1) and is on time (#4) regardless of how well written (#2) and how few lines of code they use (#3). For a non-critical project these incentives may be fine, but I highly recommend you think twice about it for more important projects.

Incentive is the key word here. If you know anything about psychology or economics, you know that incentives have a powerful affect on humans.

That said, most developers, myself included, are going to try to do what is best for you regardless of incentives; but a fixed price contract sends the wrong, strong message.

You Don’t Know What You Don’t Know

Of the hundreds of projects I’ve done, I’ve never met a client that knew everything they wanted from the start. They often have a really good idea, but as we dig into the specifics, things change. Always.

Web projects are in a constant state of flux. By hard coding a price (and by extension, a scope) you make it much harder to react to important and inevitable future changes.

Changes to a fixed price contract take more signatures, effort, time, and overhead. As a consequence, I’ve seen project deadlines jeopardized, important changes never get approved, and a lot of wasted time.

Not to mention how annoying it must be to hear a developer respond to your request with, “sorry, that change is out of scope and will have to wait till phase II.” And yet, that is exactly what you’ll hear unless the developer just bites their tongue and eats the loss. I mostly bite my tongue, but that hurts. 🙂

Alternative To Estimates

I’m not naive to the fact that clients need to have budgets. So, if you need to budget with an hourly contract, try this:

Take the rough estimate and multiply it by 130%. This is your temporary worst case scenario budget.

Estimate * 130% = Budget

Then, decide a max weekly hours you’ll allow your developer to work (without you giving verbal approval). Thirty hours is a good limit for a contractor, but it may depend on your project. Use the budget divided by the max hours per week to get the total number of weeks expected to work.

Budget / Max Weekly Hours = Expected Weeks.

Use your expected weeks to re-evaluate the budget about half way through and weekly near the end. At these times, you should definitely reach out to the developer and get their take on overall progress as well. As the project is winding down, you’ll have a much more stable number for what the project will end up costing and it will likely be under budget.

Start Small

If you’ve never worked with the developer before, start with a small project so you can make sure they work well with your team and their code is quality. If needed, you can hire another developer to QA their code and provide the other developer specific feedback (emphasis on specific!).

By the way, I read and respond to comments on this post, so feel free to speak up.


About The Author

Ben currently works as a senior developer and technical business consultant outside of Boulder, Colorado.

More about this author

About Buink

Buink Web Development is a development shop founded in 2009 by Ben Buie. For years, Ben built and modified web assets for clients in Utah. In 2011, he moved the company to Colorado and in 2015 he started taking on new clients full-time.

Buink’s Core Values:

  • Cost effective technology (with business strategy in mind)
  • Eloquent, maintainable code
  • Responsive and transparent communication
  • Quick project turn-around
  • Less code, less bugs
  • Start with responsive styles

Read more about Buink’s core values

Read more about Buink

Connect with Buink

Connect with Buink via email, send us a message, or subscribe to our blog.

  • Pingback: The Hidden Cost of Poor Development |

  • TimInColorado

    I totally prefer fixed-bid contracts, in large part because even reasonable clients will balk at higher hourly rates, and clients generally prefer the certainty of knowing what they need to budget up front.

    I also hate tracking hours: If I’m working on a contract and there’s a build or upload that takes a few minutes, should I feel guilty about reading email during that time? What if I read email for longer than the delay? Do I need to punch in and out every time I look away? It’s also just another “thing to remember,” which takes up valuable mental real estate when I’m trying to actually focus on the problem at hand.

    As you point out in, the best developers can be large multiples faster than beginners. They can also be large multiples of productivity beyond an average developer. 25x is not unheard of, and it can really go up infinitely: There are some programming tasks that are too complex for an average developer to ever complete. That’s why rates of $250-$600/hour or more are sometimes paid for a really skilled, really capable developer.

    But businesses are paying for *value received*, not hours. If you can do something in eight hours that an average programmer would take two weeks to complete, and your result is *better* than the average programmer’s result, why not charge $4,000 for the result? It’s less than the average programmer would have charged, for a superior product, sooner. It’s a win-win-win for the client.

    And if your estimate for the task is off by a factor of three and it takes you 24 hours of work, then you’re still making more than the average programmer, and you’ve learned more about estimation, which should improve your ability to estimate the next task.

    The best compromise I’ve encountered is to bill-by-sprint: If I charge $X for a two week sprint with specific goals, I can reliably complete the goals in that sprint and the client knows what they’re paying for that functionality. If their goals change, the next sprint can take that into account. The total project cost can be estimated based on the initial plan and the number of sprints it should take to complete that functionality. If the plan changes, then you let the client know that the sprints will change, and that it may take one or more additional sprints to complete the project.