Что обязательно должно быть в договоре (и чего там быть не должно)

Хороший договор делает проект спокойным: вы понимаете, за что платите и что получите. Плохой — оставляет всё на “договоримся потом”, и потом вы действительно договариваетесь… но уже на нервах.

Что обязательно должно быть

1) Предмет договора понятными словами. Не “услуги разработки”, а конкретный результат: система/кабинет, ключевые функции, ограничения.
2) Этапы и результаты этапов. По каждому этапу: что сдаётся, как принимается, сколько стоит.
3) Сроки и ответственность за срыв. Не абстрактно, а с привязкой к этапам и зависимостям (“если заказчик не дал доступы — срок двигается”).
4) Порядок изменений. Как добавляются новые требования: оценка → согласование → изменение бюджета/сроков или замена объёма.
5) Приёмка: критерии и сроки. Сколько дней на проверку, что считается дефектом, как фиксируются замечания.
6) Права и владение результатом. Кому принадлежат исходники, дизайн, документы; право использовать; запрет “держать в заложниках”.
7) Доступы и передача. Репозиторий/аккаунты/домены/ключевые учетные записи должны быть оформлены так, чтобы бизнес не зависел от одного человека.
8) Гарантия и поддержка. Что входит, какие сроки реакции, что считается “не гарантийным”.

Чего в договоре быть не должно (или требует правки)

• “Подрядчик делает по своему усмотрению” без критериев результата.
• “Сроки ориентировочные” без этапов и приемки.
• “Все доработки за отдельную плату” без определения, что считается ошибкой.
• Запрет на передачу кода/доступов заказчику.
• Оплата 100% вперед без привязки к поставке результата (почти всегда риск).

Договор — это про управление ожиданиями. Чем точнее вы фиксируете этапы, приемку и изменения, тем меньше шанс переплатить и остаться без результата.