1.The IRT is to serve only its primary purposes 

The primary purposes of the IRT are to enroll/randomize patients, provide a system to manage IMP from release through to return/destruction, and be a mechanism to unblind patients. Too often the IRT is viewed as a place to collect data that belongs to the EDC, a mechanism to control site activity, or even a tool for sponsor approval workflows. 
The urge to collect data in IRT is a reflexive response to the problem that sites delay data entry into the EDC system. It is the number one reason that sponsors give for adding data collection to the IRT. My perspective is that one should channel their inner Six Sigma expert and address the root cause, which is site’s EDC delay, instead of turning your IRT into an EDC system.
Making your IRT a replacement or EDC supplement leads to downstream issues like longer development timelines, additional validations, reconciliation nightmares, and site frustration.

2.Thou shall not defer functionality

I recognize my opposition to this practice is a bit controversial in the IRT space. This is primarily true because it is common practice and promoted by both sponsors and vendors.

When timelines are short and teams are focused on the “go live date”, they often choose to defer some IRT functionality to a future 2nd or even 3rd release to reach first patient in (FPI) deadline. My experience has repeatedly demonstrated that this approach leads to inefficiencies, compromised quality, and regulatory misalignment.
I have been the victim of a deferred functionality quality failure. The cause of the failure was directly attributed to the functionality being designed and implemented after the initial “go live” when the context of the whole of the feature was not fully understood. This is even more likely to happen when “Change Control” development resources are brought in rather than the original development team.
In a past life, my organization had a finding by a regulatory authority because we put a system live that was not 100% in alignment with the protocol as written, having chosen to defer functionality that was not immediately needed. I was surprised by the finding but the discussion with the inspector helped me see the light. The expectation was that even a protocol with a long open label run-in period must deploy unblinding in the initial go live if there is a future blinded part of the regimen.
I have written a full article in Applied Clinical Trials Online (November 2022) on this topic and encourage you to read it.