Договор со студией или разработчиком почти всегда начинается одинаково: “сделать фичи”, “сдать в срок”, “оплатить по этапам”. А проблемы всплывают позже — когда нужно доказать права на код, забрать исходники, перенести проект в другой подряд или защититься от претензий по качеству. Ниже — базовый набор пунктов, которые стоит проверить в первую очередь, чтобы договор реально защищал продукт.
Первое — права на результат. В договоре должно быть прямо написано, что именно вы получаете: исключительные права или лицензия, на какой объём работ это распространяется (код, дизайн, тексты, документация), и когда происходит передача — по факту оплаты, по акту приёмки или по этапам. Важно, чтобы права переходили не “когда-нибудь потом”, а по понятному триггеру, иначе вы можете оплатить работу и всё равно остаться без юридически закреплённого права использовать результат.
Второе — доступ к исходникам и репозиторию. Если разработка идёт в Git, лучше сразу определить: чей репозиторий, кто владелец организации, кто админ, кто имеет право делать merge, и что происходит при расторжении. Минимум — у вас должен быть доступ уровня owner/admin и обязанность подрядчика регулярно пушить код в ваш репозиторий, а не хранить всё “у себя”. Это же касается дизайна (Figma), инфраструктуры, доменов и любых аккаунтов, без которых продукт не живёт.
Третье — приёмка и критерии “сделано”. Приёмка — это не формальность, а точка, где закрепляется результат: что именно считается выполненным, как вы тестируете, сколько времени на проверку, что считается дефектом, и как работает цикл правок. Без этого легко получить ситуацию, когда подрядчик говорит “мы сделали”, а вы — “это не то”, и спор превращается в переписку без опоры на договор.
Четвёртое — ответственность и гарантии. Важно заранее договориться о пределах ответственности: лимит, штрафы, сроки устранения дефектов, компенсации за простой, а также о том, что подрядчик не нарушает права третьих лиц. Особенно критично — гарантия по оригинальности результата и правила по использованию стороннего кода/библиотек: иначе вы можете получить “готовое решение”, которое юридически нельзя использовать или нельзя коммерциализировать.
Пятое — конфиденциальность и реюз. NDA само по себе не всегда спасает, если в договоре не прописано, что подрядчик не имеет права использовать ваш код/дизайн/решения повторно в других проектах (или что такие условия строго ограничены). Для продукта это часто принципиально: вы платите за результат и хотите быть уверены, что ключевые части не “переедут” к кому-то ещё.
Если коротко: хороший договор отвечает на три вопроса — кому принадлежат права, где лежат исходники и что считается завершённой работой. Всё остальное можно обсуждать, но эти три блока лучше закрывать сразу, ещё до начала разработки. Если хотите, можно начать с быстрого ревью: вы присылаете текущий договор и контекст проекта, а мы отмечаем риски и предлагаем конкретные правки по ключевым пунктам.
