Как строить отношения с разработчиком?

1. Дизайн можно делать параллельно с разработкой кода, т.к. этими вещами занимаются разные специалисты. Дизайн на начальной стадии не будет лишним в том числе для разработчиков, визуализация идеи никому не помешает. Если дизайна нет, то простые макеты (мокапы) должны быть неотъемлемой частю ТЗ. Само ТЗ может попытаться написать заказчик, но по моему мнению будет лучше, если этим займется специалист с опытом решения таких задач на стороне разработчика, по результатам общения с заказчиком.

2. "потом с ним что-то случилось и он пропал" - от этого никто не застрахован, но лучше пытаться избегать пропадающих разработчиков еще на этапе отбора. Как минимум это договор. По возможности рекомендации. Личная встреча, если это не проект за 300 баксов, в наше время перелеты не стоят запредельных денег. Копаться в чужом коде проблем нет - вопрос только в том, что в нем увидит принимающая сторона, и будет ли смысл продолжать в том же духе. Проекты разные, разработчики разные, часто просто по трудозатратам видно, что проще переделать все с нуля, чем пытаться залатать брошенный проект. Иногда все ок. Любой случай рассматривается индивидуально.

3. Зависит от проекта, в каждом случае лучше консультироваться со специалистом, если у вас нет опыта в выборе платформы.

4. Работа с продуктом не должна причинять дискомфорт пользователям. Если есть проблема с производительностью, ее должен решить разработчик, не важно что это будет, рекомендация к улучшению железа или оптимизация кода или запросов. Все остальное от лукавого, "так и должно быть, это ограничения языка" - такие объяснения не принимаются, ты специалист и должен заранее предусмотреть нагрузку и требования к железу/коду.

5. Имхо очень нужен архитектор для разработки ТЗ/мокапов и менеджер для постоянной коммуникации с вами. Остальное зависит от проекта

6. Мое мнение, чем больше возможности общаться между собой у участников проекта, тем быстрее идет процесс и качественнее результат на выходе. Поэтому я бы отдал проект сработанной команде. Ну и конечно для вас это много сэкономленного времени и нервов.

7. Фрилансер или студия, границы размыты ))) студия вполне может состоять из фрилансеров ) повторюсь, хорошо если это команда с хорошим опытом и ответственным лицом. Ну и про договор не забывайте. И права на код - вам уже выше написали - они вполне четко ложатся в договор, это должно быть нормой.

А как оценить стоимость на самом начальном этапе? Ну хотя бы порядок, чтобы понимать стоит ли вообще влезать в это? Есть какие-то методы?

Спросите у трудящихся,

сколько они хотят за работу.

Умножьте их желания на три.

Если повезет,

то хватит.

При грамотной организации труда достаточно спроектированных интерфейсов, тогда дизайн и макетирование удётся запустить параллельно разработке. Это чуть дороже, но проект делается быстрее и предсказуемее.

Как можно писать код без документации я уже давно не понимаю. И как она может устаревать, если встроена прямо в код - тоже. Более того, практика показывает, что ранее не писавшие документацию програмисты начинают её писать достаточно быстро когда понимают, как её использовать: современные средства разработки при наличии документации позволяют банально меньше создавать невынужденных ошибок (описок, неправильных наименований методов и т.д.), а так как программисты ужасно нелюбят искать в коде ошибки, то втягиваются в документирование.

И вообще, если код не отформатирован под общий стандарт, если все методы классов и их параметры не описаны, если на сложные классы нет модульных тестов, то это не код, а барахло какое-то низкосортное. И это барахло оказывается существенно дороже, чем код, на который потратили дополнительные усилия.