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]
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...