Иногда нужен гибкий подход к разработке. Например, когда заказчик только примерно понимает, какой результат хочет получить. Или если требования к продукту обновляются по ходу разработки. Здесь отлично подходит формат Time&Material, с привязкой оплаты к часам работы. В этом случае ТЗ точно будет лишним.

Для простых и понятных задач — есть шаблонные и предсказуемые решения. Если разработка займёт пару недель, то тратить время на техническое задание ― неразумно.

Если вы уже сотрудничали и убедились в адекватности друг друга, то жёсткие рамки ТЗ будут лишними. Они демотивируют разработчика и требуют дополнительных трат со стороны клиента. Поэтому лучше просто оговорить бизнес-требования и итоговый результат.

Работать с готовым проектом — сложно. Вам придётся вникать в код, изучать архитектуру и чужие «костыли». А это — деньги и время. По опыту — минимум месяц. Поэтому сделать ТЗ на стадии планирования — практически невозможно. Объясните эти моменты заказчику и решите нужно оно вам обоим, или нет.