There are two popular approaches to contracting with a "dev shop" or software consultancy. The most common option is an hourly rate, also known as “time and materials.” The other, less common offering is "fixed price" or "fixed bid." In this article I'll summarize the highlights of each.
This type of contract is most popular. The software consultant will generally provide a detailed proposal that will include the following:
There are a couple of things to keep in mind when looking at this type of contract.
First, scope is always wrong. Every software project starts with a vision of what needs to be done, but building software is primarily a learning experience for developers and stakeholders. As the initial layers are built, new ideas, constraints, and options reveal themselves, requiring the team to adapt as they go. You may realize that you want to add that wasn't foreseen, or the developers may discover obstacles that had not been predicted at the start.
Second, estimates are always wrong. Even seasoned engineers agree that software estimates are nothing more than educated guesses and are rarely correct. The longer the timeline (say, more than a couple months), the greater the margin of error.
As you can see, software projects often end up with cost and time overruns as the project progresses. And the longer the project, the larger the overruns.
The obvious consequence of a "time and materials" contract is that it places the risk squarely on you, the project owner.
A less common option is a “fixed price" contract. (Disclaimer: this happens to be my preferred option and you can learn more here). With this kind of contract, that the price your dev shop provides a total cost that is guaranteed.
Yes, that's right: the cost is guaranteed, regardless of how many hours your dev shop ends up taking to build the software. This is good news for you, because it means that the dev shop has absolutely no incentive to extend the timeline, nor any incentive to deliever low-quality software since they will have to fix any problems on their own dime.
With this kind of contract, the risk lies solely with the dev shop. The bottom line: with a fixed-price contract, you're more likely to get high-quality software, on time, and within your budget.