|
|
|
|
|
by flyinglizard
2362 days ago
|
|
If you're in familiar territory, the product is well defined and the customer is reasonable - go for project billing. An example would be implementing some low level function for an embedded device. Anything you know is going to only take a few hours, bill per project (unless of course it's an extension of an existing hourly contract with a customer). Anywhere there's upside or difficult circumstances (such as unreasonable timeline due to external requirements, such as an upcoming event or demo), charge per project. But to be in that position you first need to build a stable revenue stream and that happens more easily with hourly consulting. |
|
It isn't unlike tying your contract to the behavior of a poorly documented remote API provided by another company that won't respond to any of your requests.
The risks include: the hardware being flaky. The hardware being undocumented. The hardware having no run control. The function relying on another piece of hardware or environment not provided.
I once spent two weeks looking for a single bit not-so-helpfully labelled "WinCE" in Texas Instruments' documentation.