Я предлагаю определиться с порядком работы.
1) Однозначно определиться кто участвует, чтобы было понятно на кого вообще можно рассчитывать, а кто мимо проходил.
2) Выработать внятные требования к результатам. Все это закрепить в отдельной теме, к которой можно будет возвращаться в случае спорных моментов
3) Разделить разработку на части и поделить их между разработчиками. Если это возможно
4) Обсудить и утвердить результаты в соответствии с требованиями выработанными в первом пункте
В результате будет схема, которую замораживаем и на основании ее рисуем плату.
Я не знаю кто как, но при цене платы, допустим, 100$ тратиться на нее дважды как то не очень хочется. То есть сначала будет полуфабрикат, который мы сознательно делаем непригодным для полноценной эксплуатации, а потом уже нормальную плату. Вероятность того, что полуфабрикат даст дуба в процессе разработки даже выше, чем в процессе эксплуатации.С защитами можно пока и принебрегать, делать так сказать полуфабрикаты, чтоб програмисты не простаивали.
Считаю правильным ориентироваться на работоспособный уровень. Да, потом можно улучшать и вылизывать, но в некоторых пределах улучшать уже можно готовое. Если же изначально закладывать ущербное, то развивать его будет нельзя.
Но это уже для второго пункта работа. Сначала надо определиться кто в деле.