I’ve been doing contract development long enough to know what the market will pay for my services and skills.

That said, I’m still surprised by people who won’t. They choose to go with cheaper, less experienced developers or overseas developers because of the lower rate.

Let’s investigate (dear Watson) why a higher rate may be cheaper in the end. Let me know if you think any of these reasons are off base.

Your Time is Valuable Too

I’ve been meeting on a weekly basis with a couple entrepreneurs to share business concerns and get advice. This week, one of the entrepreneurs asked our thoughts about hiring an overseas contractor to develop his first website. Another entrepreneur, I’ll call him Bob, shared the story of his first site. “I was surprised by how much testing I had to do,” he said, “by the end of the project I’d lost all motivation to even go forward with the business because testing was so tedious.”

I know exactly what Bob meant, my first site was the same. I literally had to test every button, every link, every hover state, every requirement, everything! I was blown away by how much stuff was missed. Catching these little details was expensive. Not only did I waste my time, but I had to wait for a fix when I should have been more focused on the overall business.

Developers eventually get better at catching problems, and no developer is going to catch every bug and every missing link, but these should be the exceptions, not the rule.

Foundation is Important

When building a house, you start with the foundation, add walls, and top it with a roof. When building a website, you start with the technology you’ll use (Node.js or Laravel backend, Angular front-end, SCSS, Grunt, etc.) then you build the overall architecture (folder organization, routes, etc.), and then you start adding the pages, snippets, plugins, etc.

Although it is a good practice to keep code independent of other code, a good foundation coupled with building reusable code snippets, directives, and plugins makes it easy to add functionality through the whole site without copying and pasting. This means fewer lines of code, which are usually cheaper to write and always cheaper to maintain.

A great example of code building on itself is CSS. A developer implements the design of the overall site (header, footer, H1 tags, etc.) that is reused everywhere. When you add styles to a specific page, you don’t have to re-design the header and footer, the page inherits the overall site styles and allows the developer to just tweak the design based on a page’s need. If the CSS foundation is weak, you’ll find that you have to add a lot of styles to a page that should have been added at the site level. More code, more money. Also, a future developer may want to go back and tweak the site level styles to save time in the futrue, but this is costly because every tweak to the overall styles means they have to test the whole site for bugs.

All too often, businesses neglect the importance and value of setting a good foundation. They’ll bring in a cheap developer at the beginning thinking they’re getting value. Later, when the site isn’t performing or is cost prohibitive to update, they’ll bring in a more experienced developer who usually calls for a re-write.

Lost in Translation

The #1 reason to work with someone who speaks native English is that code is hard enough to communicate without a language barrier.

I had a potential client reach out to me recently, I’ll call his company GameChanger. They had worked with a developer in Vietnam for a very low rate (about 1/9th my current rate) but they decided to find a local resource. Why? Because they had been loosing a lot of time and money in translation. In other words, GameChanger would ask for a change, the developer made the change thinking they understood, GameChanger would review the change only to find out the developer didn’t understand. Not only did the developer waste valuable time and money doing something they shouldn’t have, GameChanger wasted time communicating the change and reviewing it. Then, the launch date get’s pushed back and more money is lost.

This must happen more than you’d expect because I’ve had the same exact experience multiple times. Cheaper is sometimes more expensive.

Debugging is Hard

Sometimes things just don’t work like they should. What is worse is that many times broken code doesn’t explain itself. There is no substitute for experience. Books won’t help you because no one writes books about bugs; they just fix them, if you’re lucky. If you’re unlucky, you fix them yourself.

I remember in the early days of coding that debugging would sometimes take more time building. With experience, however, I’ve become exponentially better at finding the source of the problem. Killing bugs take both a solid foundation of the fundamentals of a language and real-world experience hunting them down.

You’d be surprised how much a trained bug killer can save you.

Half the Price vs. Twice as Fast

In the world of development, time really is money. With an hourly contract, which I highly recommend, the important question is, would you be better off with half the price or twice as fast? Think about that, which is better? They seem to be the same until you realize that fast also means less bugs, a better foundation, better communication, and faster debugging.

The learning curve for becoming a seasoned developer is slow but exponential. In the begining, we spend a lot of time just getting the basics of a language. The first time we write a function takes a surprising amount of time due to stupid mistakes. Stupid mistakes are the most challenging because no one writes about them; they’re too obvious to everyone but beginners. Soon functions become second nature and we start learning about objects. Later, we move into learning different libraries, frameworks, and packages. Many of the things we learn span the whole language and development in general.

It may take as much as 10 times as long to do something the first time as it does to repeat it; typically it’s about 3 in my experience. After years of experience, I’ve seen things take me 1/50th of the time it did in the beginning and the curve keeps going. In other words, an experienced developer can provide about 3X the value of a beginner and sometimes as much as 50X.

Again, sometimes a higher price is less expensive.

Conclusion

It is natural to want the most value when choosing anything, particularly a developer. Just keep in mind the counter intuitive truth that a lower rate doesn’t necessarily mean more value.

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.