- 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 are to entertain a fixed-price project.
- If your hired developer is not performing, you can nix them at any time.
- You might actually get a better deal, especially if 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’ll end up having to pay out-of-pocket for needed changes after the initial version is done. Worse, if your project is rather complex, the fixed-price will likely be inflated because the developer will have a hard time accurately anticipating the scope of your final expectations, and needs to factor that risk into the price. With hourly, you pay only for the time spent.
- 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, all for the benefit of you and your final product.
- My two cents: Hourly development contracts are simply the only way to go for designs or optimization-type work (like code refactoring or server performance tuning).
Here’s the catch, though. Even if you go into an hourly contract for all the right reasons, you still need to be proactive to ensure success.
In the same way that hourly contracts attract better talent, they also attract predatory developers that charge higher prices. That’s because they think they can get away with charging longer hours since they believe 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, keep in mind that 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 aren’t cut out for it:
- Be a communication keener. 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, you can test new developers 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 are motivated by more than money–they’re invested in the long-term since there is no “final date”. So get creative, and let your developers and designers do the same.