How To Get The Most Out of Hourly Development Contracts

To better understand why you would seriously consider an hourly contract when clients usually prefer fixed price contracts, here are several not-so-obvious advantages of hourly contracts:

1. You’ll typically get better talent. One of the trends you may notice is that the more hours a developer has on their belt, the less likely they will entertain a fixed price project.
2. If they’re not performing, you can nix them at any time.
3. You might actually get a better deal. When you know you’re prone to changing things in the middle of a project (like most clients are), with a fixed price you’ll end up fighting with the developer to get it done or you end up having to pay for the change after the initial version is done. Or if your project is pretty complex, the fixed price will likely be inflated because the developer will have a hard time estimating accurately and needs to factor that risk into the price. Hourly = you pay only for the time spent.
4. Developers start to care more about your success. Fixed price projects are not good for iterative development where you want to try things one way, test it, and make changes to it based on metrics or feedback. Hourly contracts incentivize developers by compensating for creativity and willingness to experiment for your benefit.
5. Hourly is simply the only way to go for designs or optimization-type work (like code refactoring or server performance tuning).

Here’s the catch. Even if you go into an hourly contract for all the right reasons, you still need to be proactive to ensure success.

Just like hourly contracts attract better talent, they also attract predatory developers that charge higher prices because they can get away with it or charge longer hours because they think clients don’t know what’s going on under the hood. Here’s how you can catch these sharks early:

• Get estimates from clients for features. Even if these are fast and loose, you need a point of reference to keep the developer accountable.
• Hire another independent developer to review their code and tell you if they’re actually doing a good job.

Also, not all developers are cut out for iterative development. Some are better off being given a set of well-defined tasks. Here’s how you can sniff out the ones that are cut out for it:

• Be a communication nazi. Iterative development is a collaborative exercise so there should be daily updates, idea exchanges, rapid response times, and honest conversations about areas needing improvement.
• Provide early opportunities for creativity with small scopes, so can you can test developers on them without breaking the bank. Can they suggest good solutions for a frequent UI complaint and then measure engagement changes on their own? Can they improve the loading speed for a small set of data?

Using these steps, you should in time be able to find developers that can not only code efficiently by the hour but also solve problems creatively for you. Who knows, this may even lead to cofounder material. Let me know if this helps you!

If you find our musings amusing, subscribe to us here!