I suggest deelply using event based development.
One great feature is that although we do not save some data into contract storage, we still retrieve data from blockchain (from contract state) using events. Consequently, we do not "save" anything on front-end.

More specifically:

• minutes delivered and logTimestamp (ITERATION state) could be emitted (ApplicationAdded event) and retrieved from the contract events. This data is view only for front-end, so we can remove it from contract storage.
• getState, getReviewer, getClient, getContractor and other view functions could be replaced with event handling. For example: for each contract we have a number of events that signals current contract state. So on front-end this task ends-up in getting last state signaling event. Just for now we have DealInitialized, ReviewerProposed, ReviewerAcceptedConditions and ReviewerDeclinedConditions, ContractorChosen, LoggedWork, IterationFinished, DealTaskReviewedPositively, DealEndedUp(currentState). So, we can use them as state flags. These events also contain information, related to deal current state: client/contractor/reviewer addresses, minutes logged, iteration stats and e.t.c.

I suggest adding deal options (task description, short name, iteration duration in seconds, mean of payment) update behaviour. Also finishing deal from INIT state will be more suitable for UX.

It seems that there are some issues, when contractor/client/reviewer are contracts. It is ok if they have fallback functions, because transfer method is considered safe: it reverts if exception is met, it gives very few gas, so re-entrant call can't be performed.But we can really face problems if deals currency is ether and one of those actors is a contract without fallback function - deadlock.

Possible improvements:

• checking if address is a contract;
• change logic of reward transfer to "pull" over "push".

One of our projects (pchela-computing) had similar to trust-deal (on ITERATION and REVIEW states) timeout constraints. Logic there was implemented with _stageTransitionDeadlineVar which was rewritten to now every time state was moved forward.

For example, when we move to ITERATION state, we write to storage iterationStart = now. Every time work is logged, we check, that iterationStart.add(iterationDuration) > now. Same logic with REVIEW state. So, I suggest using one _stageTransitionDeadlineVar, which is assigned to now every time state goes forward (in newIteration and finishIteration funcs)