Charge per Hour or per Project?

Consider this, a crucial element of business is risk management. People and companies who don't wish to manage a particular risk will choose to outsource it.

For example, by paying an insurance company $x per year, I can be pretty confident that my legal liabilities for my [car, house, etc] won't exceed a certain amount per year.

In the case of certain projects, companies who are looking to reduce their risk look for fixed-price contracts.

In a fixed-price contract, much of the risk of the project is on the vendor's side.

So the vendor who offers a fixed-price contract has to be very confident, that they have done similar projects many times before, are very familiar with the costs and risks, and have reliable paperwork, processes, and people who mitigate all the risk factors on a daily basis. If the vendor manages the risk well, and successfully implements the project, they can make a good profit.

When you as a vendor offer a "time and materials" contract, or hourly contract, you have much less risk. The hiring company is taking all the risks, that the project scope is well defined, that the people and processes work properly, and that the work is performed efficiently.

So the question really goes back to you, do you have project types where you have lots of experience, and can confidently offer a fixed bid? If yes, put together a very solid proposal, with a tight SoW and very detailed contract terms. In the course of the project, manage the risk daily, and raise a red flag quickly in case of problems.

If not, avoid the risk, and stay on a time and materials basis.

One approach is to do the "per project" thing and wildly pad the charge to allow for uncertainty. This can protect you from losing money on a project that goes poorly, and can yield a big windfall on projects that go very well. But it can result in quotes that scare prospects away, and still can't guarantee that you don't lose money in the worst case.

Another option is to do the "per project" thing, do really extensive requirements analysis up-front, and then be absolutely rabid about enforcing the change control policy. Since one of the biggest reasons for uncertainty is changing requirements, make absolutely sure that your contract reflects a "if you change anything from the initial requirements then we re-negotiate the budget" mindset. The details of you how express that can be pretty varied, of course.

You can also combine those two options.

Is any of this a good idea? It's arguable. People have been working this way for a very long time, but both approaches, or the combination can easily lead to adversarial relationships between vendor and customer, and can result in a lot of acrimony and antagonism.

Arguably a better approach is to adopt the idea of "Agile Contracts"[1][2][3][4]. One problem with this is simply that it's a newer approach and something that a lot of people aren't as familiar / comfortable with. Selling customers on this approach may take some extra work. But it might just be worth it.

There's a lot more that could be said about this, but it's not easy to condense into a quick HN post. FWIW, a few books that might be worth reading as well include:

1. Software by Numbers[5]

2. The Economics of Iterative Software Development[6]

3. Software as Capital[7]

[1]: https://en.wikipedia.org/wiki/Agile_contracts

[2]: https://agilecontracts.org/

[3]: https://www.contractworks.com/blog/three-types-of-agile-cont...

[4]: https://www.scaledagileframework.com/agile-contracts/

[5]: https://www.amazon.com/Software-Numbers-Low-Risk-High-Return...

[6]: https://www.amazon.com/Economics-Iterative-Software-Developm...

[7]: https://www.amazon.com/Software-Capital-Economic-Perspective...