Договор с клиентом: 7 пунктов, которые защищают разработчика от споров и переделок

Если договор нужен «для галочки», проблемы обычно начинаются на этапе правок, оплаты и передачи кода. В рабочем договоре должны быть не общие слова, а конкретные правила взаимодействия.

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

Отдельно проверьте, чтобы в договоре не было фраз вроде «по усмотрению клиента» без критериев. Такие формулировки почти всегда работают против исполнителя: спорить потом приходится не о качестве, а о том, что вообще было обещано.

Если проект идёт по почасовой модели, добавьте правило учёта времени и порядок согласования дополнительных задач. Это проще, чем потом объяснять, почему «ещё одна маленькая доработка» заняла два дня.

Хороший договор не делает работу сложнее — он заранее снимает спорные места. Если сомневаетесь, сначала опишите процесс на одной странице, а уже потом переносите его в юридический текст.