A few points to illustrate why we feel hourly pricing is better than fixed price and to mitigate some fears of flexible pricing.
Software specification
A fixed price contract states for x dollars the developer will build y software project. The dollars part is easy to understand, it is just a number. The shape and size of the software project is much harder to define. Unlike a physical product such as a house, clearly defining a piece of software is complex, time consuming and likely to be wildly inaccurate.
At time of writing this, I have been developing software for 26 years. I have never seen a software specification that comes even remotely close to providing the developer with enough accuracy and detail to build the software without further clarification. If the specification does not exist, it is impossible for the customer and the software developer to know what the finished product is meant to be.
If the finished product is not known the fixed price dollars are meaningless.
Teamwork
Fixed price contracts push customer and software developer in opposite directions. Customers have high expectations and will want the software to do everything they believe is in the specification. After all they paid their money and expect to get a certain product. The software developer is trying to deliver the product, and to do so as efficiently as possible. The developer will do as little as necessary to meet the requirements of the specification. There is always a gap between what the customer expects and what the developer is building. The two parties are forced to work against each other.
With an hourly rate approach, we are constantly working with the customer evaluating each feature as it comes up. We are able to invest more or less effort in each feature depending on the importance to the customer. The main point is we are working with the customer to build something that works for the customer today, not against the customer trying to meet a specification defined in the past.
Budgeting
The first and obvious objection to using an hourly rate is not knowing how much a software project will cost.
To be clear, hourly pricing does not make for an unlimited budget. We have customers who give us clear budgets to stick within. Hourly pricing allows us to deliver the best value we can within the budget.
Working with a budget gives the customer a known price, but allows the software developer to pick the best value items to include in a project now and to delay less important items for later phases.
Transparency / Simplicity
Like many consumers I dislike weird, wonderful and complex pricing. Take the price of airline tickets increasing in a hap hazard fashion as the date of travel gets closer. Or the price of Apple products where a model containing $15 worth of extra storage component costs $200 more to purchase. Or a keg of beer costing 50% more than purchasing the same quantity of beer in small, wasteful bottles.
Businesses who sell generic products need to adopt these pricing practices to maximize the amount of money they can make out of each customer. In my naive view of the world, I feel pricing should be transparent. Cost to make a product, plus some margin determines the selling price. Pricing a software developers services by the hour provides total transparency. We have developed an in house time recoding system. Developers record their time and these records are included with our billing, so the customer sees exactly what the developer has worked on.
The cost of pricing
To figure out the price of a software project is not free. A software developer needs to scope out the project and create enough of a specification to figure out how much it should cost. This exercise requires the time of programmers, analysts and other experts. Ultimately, the customer pays this cost.
Risk
Any building project, software or physical building, has a significant risk component. There is a risk of unforeseen issues cropping up which require time and money to fix. The question is who takes this risk.
In a fixed price contract, the risk normally sits with the supplier. To accept the risk, the supplier needs to factor the potential costs into the price, passing the costs onto the customer. The customer is within their rights to insist the developer address the issue even if the fix is not a good use of resources.
With hourly pricing, unforeseen issues are tackled as they come up. The customer can opt to spend more money to fix the issue or to accept the issue and keep their money.
Opportunity
As a software project progresses new opportunities present themselves. There are always new and better ways to achieve the same or better outcome. Technology is constantly improving. Developers are always training and learning new ways of doing things.
When new opportunities present themselves, we suggest them to the customer and implement them when it makes sense. We do not like having our hands tied by a ridged specification and contract. If there is a better way of building a component we want to take advantage of it. Or even delaying a component because we are expecting a new technology which will make the component better or easier to build.
Fast, cheap and high quality
There is an old saying of software development project managers. We can build any project fast, cheap and high quality, please pick any 2.
Obviously this saying is tongue in cheek, however there is real truth in it. It is not possible to built quickly, cheaply and keep quality high, one of these things needs to give.
A customers priority will vary between projects and components. Sometimes a customer will want a quick, low cost addition to their software, for example, maybe a report to indicate the average size of a sale. Other times the software needs to be high quality and 100% accurate, such as when totalling money for accounting or tax purposes.
Hour pricing allows for this flexibility. The cost of a project adjusts itself depending on requirements for speed and quality.
Software is malleable
When building a house, most of the design needs to be agreed before building. Once the house is finished, you don't expect the builder to move the kitchen from one side of the house to the other.
Software on the other hand is far more malleable. It is often possible to make significant modifications with minimal effort. Customers start to enjoy the ability to chop and change their mind.
We prefer to say yes to a customer. Yes we can change or improve something. Hourly pricing allows us to say yes more. Small changes will only cost a little extra and just get done. With larger changes we warn the customer and give them options.
The finish
Putting polish on an application or website is often the most time consuming part of the exercise. Hourly pricing allows us to adjust the level of finish depending on a the customers requirements.
Components visible to external users will often need a higher standard of finish than components used in house. Components which are used frequently will get a higher level of finish compared with components which used once in a blue moon.
There is no need for a customer to pay to perfect software components which are only used occasionally by a small group of people.
In Conclusion
Fixed price software contracts fail as custom software development is to difficult to specify and predict accurately. Fixed pricing leads to a poor working relationship between customer and developer.
Pricing by the hour produces a lower cost, higher quality, better value product for the customer. It works well for our loyal, long term customers and dove tails nicely with our Agile software development methodology.