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):
- It works (happy client)
- It is well written and readable (maintainable)
- It is written with as few lines of code as possible (maintainable)
- It is on time (speed)
- 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.
