Договор на мобильную разработку

Введение

Приготовьтесь, это длинная инструкция, в которой мы расскажем, как составить договор, который будет выгоден обеим сторонам: и Заказчикам, и Исполнителям. Такой подход не только снижает риски каждой стороны, но и существенно сокращает время на согласование документа.

В конце материала вы найдете готовый шаблон договора на мобильную разработку + шаблоны соответствующих приложений к нему. Специально для вас их подготовила команда Runetlex, которая специализируется на подготовке документов IT-направленности.

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

Ключевые моменты в договоре

Вначале перечислим несколько самых главных принципов, на которые стоит опираться, адаптируя под свою специфику столь важные документы.

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

Если исполнитель не имеет права разглашать какие-то данные о сотрудничестве предварительно не заручившись согласием другой стороны, то и заказчик этого тоже не имеет права делать.

Не должно быть двусмысленностей или размытостей в формулировках. Юридические документы не должны содержать формулировок, которые можно воспринимать двояко или в которых отсутствует конкретика. Для примера: «Исполнитель обязуется выполнить работу качественно». Это не чёткая формулировка. Не понятно, что именно значит «качественно». Это очень субъективно. Гораздо понятнее вариант, при котором заказчик может отказаться от приема результатов работы только в одном случае - если эти результаты не соответствуют Заданию.

Еще часто используют такую формулировку: «Заказчик обязуется оплачивать выполненные работы своевременно». Здесь не понятно, что значит «своевременно». Этот критерий должен в чем-то измеряться. Правильный вариант — указать конкретное количество дней с момента приёмки работ. Но тут возникает следующий вопрос: а если Заказчик оплатил, но несвоевременно? А если вовсе не оплатил счет? Значит, нужно добавить в этот пункт детали о том, чем чревато нарушение. Например, указать, что Заказчик обязан произвести оплату не позже стольки-то дней после подписания акта и, если этот срок будет нарушен, должен заплатить столько-то процентов от суммы к оплате за каждый день просрочки. Согласитесь, здесь понятны и сроки, и ответственность Заказчика.

Учет особенностей проекта и специфики бизнеса сторон. Общепринятые правила подходят не для всех случаев, поэтому договор и приложения необходимо адаптировать под свою ситуацию. Например, когда стороны подразумевают сотрудничество строго в удаленном режиме или же оплата возможна исключительно по оригиналам документов. Такие моменты нужно обязательно зафиксировать письменно.

С принципиальными моментами разобрались. Переходим непосредственно к тексту договора. Разберем его пункты по отдельности.

Предмет договора

Этот раздел предназначен для описания работ, которые должен провести подрядчик. В самом договоре вполне достаточно будет такой формулировки:

1.1 Исполнитель обязуется выполнять работы и оказывать услуги по заданиям Заказчика, а Заказчик обязуется принимать и оплачивать их.

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

Заказы

В Заказах прописываются условия предоставления услуг: сроки реализации, стоимость работ, способы отчетности и т.д. Такой подход позволяет заключать договор с подрядчиком единоразово, по мере необходимости отражая в приложениях к нему разные услуги, которые за время сотрудничества будет оказывать подрядчик. Например, вначале клиент может заказать только мобильную разработку, а уже потом доверить этому же подрядчику продвижение готового продукта. Для каждой из этих услуг будет отдельный Заказ.

Важно также дать возможность изменять Задания. Ситуации, когда уже в ходе работ заказчик захотел что-то изменить или добавить в ТЗ на мобильное приложение — не редкость. Согласно нашим опросам, такое случается в 40-45% случаев, так что лучше сразу обозначить, что, если Заказчик будет менять Задание, Исполнитель имеет право изменить сроки выполнения и стоимость работ.

В некоторых случаях есть смысл оставить возможность предоставления и получения услуг без подписания Заказов. Мы предлагаем такую формулировку:

2.3. Если стоимость работ/услуг меньше 10 000 (десяти тысяч) рублей, Стороны могут оформить Задание без подписания Заказа. В этом случае Задание считается согласованным Сторонами, если Заказчик оплатил счёт Исполнителя, в котором содержится перечень работ/услуг, их стоимость и срок выполнения.

Должны заметить, что не все юристы одобряют подобные свободы в договорах, однако по Гражданскому Кодексу Российской Федерации такой вариант допустим.

Материалы

С одной стороны, здесь все просто и логично. Для разработки мобильного приложения подрядчику необходима соответствующая информация от Заказчика, а Заказчик должен ее предоставить. Но обратим ваше внимание на несколько подводных камней.

У Заказчика нет необходимой информации. Распространенная ситуация. В этом случае исполнитель должен аргументировать, почему запрашиваемая информация действительно важна и, если известно, как ее получить, необходимо будет продлить сроки предоставления услуг для ее получения. Если подрядчик может обойтись без такой информации — проще про нее “забыть”.

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

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

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

Представители и субподрядчики

Каждая сторона должна указать в договоре своих сотрудников, информация от которых будет считаться официальной. Такой подход упростит процесс сотрудничества, поможет сэкономить время на коммуникациях и согласованиях, а также убережет от ряда проблем. Например, на практике довольно распространен такой негативный сценарий, когда со стороны Заказчика с подрядчиком общаются сразу несколько людей и их мнения/требования противоречат друг другу.

Также нужно учесть, что в какой-то момент для реализации задачи подрядчику могут понадобиться субподрядчики. Мы предусмотрели в договоре пункт, который не позволит затягивать процесс работ за счет согласования их привлечения, но при этом подстрахует Заказчика от возможных негативных последствий.

Финансовые условия

В соответствии с предлагаемой схемой (в договоре — только основы, а детали прописываются в Приложениях), эти пункт предлагаем прописать следующим образом:

5.1 Стороны согласуют стоимость работ/услуг и порядок расчётов по Договору в Заказе.

Обратите внимание, что в нашем примере подразумевается УСН (упрощенная система налогообложения). При необходимости вы можете изменить этот момент.

Следующим подпунктом не забудьте указать валюту для расчетов и счет, на который заказчик будет перечислять деньги.

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

Остальные детали относительно финансовых условий сотрудничества прописываем в приложениях.

Сдача-приёмка

Как мы уже вскользь упомянули ранее, практичным критерием оценки готового продукта при приемке является соответствие Заданию. Мнение Заказчика слишком субъективно, чтобы опираться на него при составлении договора с надеждой, что это может сработать в суде. В случае, если он не готов принять работы, он должен мотивировать свой отказ и оформить его письменно. В случае, если результаты работы подрядчика соответствует Заданию, они должны быть приняты.

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

Добавим, что на практике часто случается так, что Заказчик по каким-либо причинам тянет с приёмкой мобильного приложения. В интересах подрядчика подстраховаться на этот случай. Для этого необходимо зафиксировать в договоре право Исполнителя перенести срок предоставления результатов на количество дней, прошедших с момента приемки. Это распространенная практика, которая стимулирует заказчика не затягивать процесс приёмки. В нашем договоре это прописано в пп. 9.1.

Другой распространенный сценарий — Заказчик по каким-либо причинам вовсе отказывается принимать работы без должной аргументации. Во избежание этого следует сразу предусмотреть, что через сколько-то дней после предоставления отчета и акта выполненных работ, работы автоматически считаются принятыми и Заказчик должен их оплатить.

Интеллектуальная собственность

С интеллектуальной собственностью все сложнее, чем принято думать. Заказчики часто заблуждаются, рассуждая «всё моё». Важно понимать, что по факту Заказчик может требовать права только на то, что было создано в рамках договора с подрядчиком. Например, на дизайн, программный код, тексты, видео, фото и т.д. Причем, до тех пор, пока Заказчик не принял и оплатил работу, права на нее принадлежат Исполнителю, то есть Заказчик не имеет права их использовать.

Процесс создания мобильного приложения подразумевает предоставление Заказчиком Исполнителю материалов, на которые он обладает правами на использование. Если Заказчику нужно будет получить материалы для использования у третьих лиц, в стоимость услуг Исполнителя они включены не будут.

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

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

В тексте самого договора мы предлагаем отразить, что подобные нюансы будут изложены в приложениях к нему.

Конфиденциальная информация

Ранее мы уже упоминали, что обе стороны имеют право запретить другой стороне распространять информацию, касающуюся сотрудничества. Как правило, это касается данных, которые могут использоваться конкурентами. Такими данными со стороны заказчиков чаще всего являются стратегии развития или продвижения. А со стороны исполнителей — ценообразование, ноу-хау, применяемые методики и инструменты.

Начать здесь стоит с определения, что считается и что не считается конфиденциальной информацией. Далее в договоре необходимо обозначить, кто именно и для чего имеет право получать конфиденциальную информацию. Например, логично дать Исполнителю право передавать ее своим сотрудникам или субподрядчикам, участвующим в создании мобильного приложения.

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

Отметим, что для большинства мобильных разработчиков очень важно иметь возможность как-то обозначить сотрудничество для последующего продвижения собственных услуг, ведь собственное портфолио и перечень клиентов — основные локомотивы продаж агентств-разработчиков. Мы предлагаем дать Исполнителю такое право и перечислить, что именно он может использовать в своих презентационных материалах: наименования Заказчика, его товарный знак, перечень оказанных услуг.

Ответственность сторон

Перед тем, как продолжить, хотим заострить ваше внимание еще на одном важном нюансе. Когда речь идет о том, что ответственность сторон в договоре должна быть зеркальной, обычно имеется в виду, что она должна быть таковой не по размеру, а по сути. Если одна из сторон нарушает условия договора, она должна понести за это ответственность. А вот как именно и в каком размере — это уже предмет договорённости. Согласно законодательству размер пени может быть любым. Однако обычно его ограничивают рамками суммы платежа/стоимости работ. Добавим также, что снижение размера пени — вполне обычная практика судов.

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

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

Причины этому могут быть самые разнообразные, в том числе и те, которые разработчик приложения не может изменить и не контролирует:

• клиент изначально предоставил подрядчику неверную информацию о целевой аудитории или своем продукте. Такое — не редкость, не все заказчики хорошо знают свою ЦА;

• менеджеры заказчика не качественно обрабатывают запросы потенциальных покупателей или вовсе не всегда снимают трубки;

• сами товары не привлекают покупателей, они им не нужны;

• заказчик установил на товары неконкурентную цену;

• специалист по рекламе сделал неверные настройки и привел в приложение посетителей, не являющихся целевой аудиторией товара и т.д. и т.п.

Говоря проще: если пользователь нажимает на какую-то кнопку в приложении и затем ничего не происходит или при оформлении заказа не срабатывает скидка — это явно ошибка разработчика. А такой критерий оценки проекта как деньги на счету Заказчика — это не ответственность разработчика, а результат стечения нескольких обстоятельств и работы разных людей, в том числе и со стороны Заказчика.

Если заказчик не платит...

На этот случай следует предусмотреть пени, обозначив ее размер. Далее, как обычно, не забываем обозначать сроки, а также указать, что, если Заказчик не будет выплачивать и пени, Исполнитель вправе остановить работу. Если оплаты не последует и далее, то следующий этап - обращение в суд.

Если исполнитель затягивает или не выполняет работы…

Здесь мы видим три возможных сценария:

• если срок задержки небольшой, проще “простить и забыть”;

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

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

Обстоятельства непреодолимой силы

Они же пресловутые форс-мажоры — то есть то, на что стороны не могут влиять, а значит, не могут нести ответственность за последствия этих обстоятельств. События 2020 года красноречиво проиллюстрировали, что их ни в коем случае нельзя игнорировать.

Для начала в договоре с помощью стандартных формулировок стоит перечислить, что именно считается форс-мажорами (пожары, пандемии, наводнения, военные операции, экономические и политические ограничения и т.д.), а затем детализировать сроки и порядок действий сторон.

Далее не будет лишним указать, что в случае, если обстоятельства непреодолимой силы или их последствия затянутся (например, на 30 дней), стороны должны будут найти компромисс: либо расторгнуть договор, либо договориться о способе исполнения своих обязательств.

Споры

Думаем, все согласятся, что споры лучше всего урегулировать без/до суда. Очевидно, что одна сторона окажется проигравшей и не всегда заранее очевидно, какая именно. Но и выигравшая сторона тоже будет в минусе. Даже если нервы не в счет, она потеряет как минимум время, а, возможно, и деньги. Исходя из этих соображений, в случае наступления спора (перед обращением в суд) практично обратиться к юристу для оценки перспектив судебных тяжб. Вполне может оказаться так, что разумным решением будут поиски компромисса между сторонами. Такую возможность стоит сразу предусмотреть в договоре:

11.1 При возникновении разногласий Стороны обязуются урегулировать их в досудебном порядке путём направления письменной претензии. Ответ на претензию должен быть дан в срок не более 30 (тридцати) календарных дней.

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

Документооборот и коммуникации

Народная мудрость “без бумажки — ты букашка” идеально подходит для описания шансов на успех в суде. Выше мы уже писали несколько наиболее распространенных сценариев, которые могут привести стороны в суд. От этого никто не застрахован, так что в интересах обоих из них грамотно вести документацию, чтобы иметь шансы отстоять свою позицию.

Не забывайте, что судьи не обязаны разбираться в особенностях разработки мобильных приложений, и не важно, речь про технологии или методы управления проектом. Чтобы понять, кто прав, и кто кому сколько должен, судьям необходимо будет увидеть результат и соответствующие документы.

Какие именно документы — собственно, и нужно прописать в этом разделе договора. Исходя из существующей практики российских судов, мы советуем использовать электронную почту (с мессенджерами в этом плане не все однозначно), а также обмен бумажными копиями.

Также необходимо указать электронные адреса Заказчика и Исполнителя. В последующем переписка должна вестись сторонами только с тех телефонных номеров и адресов, которые указаны в документах. Если нет уверенности, что удастся следовать этому на практике, можно указать несколько адресов или прибегнуть к такому приёму: «все адреса …@domenvtorogourovnya.ru».

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

Срок действия и условия расторжения

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

Важно также предусмотреть возможность для выхода из соглашения без предварительного согласия противоположной стороны. Ситуации бывают разными, и эта возможность может очень пригодиться любой стороне. Мы считаем, что никто не должен быть рабом деловых отношений. Однако честно будет дать второй стороне время для подготовки к расторжению договора - в нашем образце этот срок установлен в размере 30 календарных дней.

Прописывать в договоре подробности его расторжения по взаимному согласию нет смысла. Это уже предусмотрено в Гражданском Кодексе.

Напомним, что в случае расторжения договора заказчик должен оплатить подрядчику фактически выполненную работу. Естественно, если она соответствует Заданию и есть соответствующие акты.

А что, если предоплата была больше, чем стоимость выполненных по факту работ? Такой вариант также необходимо предусмотреть и указать, что Исполнитель должен вернуть излишек, если размер полученной предоплаты больше объема предоставленных услуг. В противоположном случае Заказчик просто производит доплату Исполнителю.

Реквизиты и подписи

В конце договора необходимо указать реквизиты сторон (все стандартно: название организации, юридический адрес, наименование банка, расчетный счет, ИНН, КПП, корреспондентский счет) подписывающих договор, а также их ФИО (должность указывать не стоит).

Ура! С договором закончили. Переходим к приложениям к нему.

Приложение №1. Заказ

В первом приложении к договору стоит указать особенности взаимодействия сторон, не изложенные ранее.

Термины

Начать стоит с раскрытия понятий, которые будут использоваться в Заказе. Так как речь идет о разработке мобильного приложения, то и терминология будет соответствующей. В частности:

Дизайн — макеты интерфейсов Приложения в формате PSD, Sketch или Figma, иллюстрации и графические элементы, демонстрирующие, как человек будет видеть мобильное приложение.

Контент — информационное наполнение Приложения: картинки, видео, тексты.

Подробнее — в шаблоне.

Общие положения

В этом разделе необходимо обозначить, что именно требуется заказчику. В данном случае — это разработка мобильного приложения:

2.1 Вид Работ: разработка Приложения для приёма заказов на еду из ресторана.

Как мы писали выше, требования к продукту будут также указаны в Задании, поэтому в первом приложении мы просто зафиксировали эту мысль в пп. 2.2. Так как обычно мобильная разработка — это довольно масштабный проект, в пп. 2.3 стоит указать, что Исполнитель будет выполнять работы поэтапно и по завершению каждого этапа стороны будут подписывать промежуточные акты.

Этапы, стоимость и сроки выполнения работ

Стороны должны заранее договориться, какой из двух вариантов они выберут:

• не фиксировать конкретные даты, но определить их последовательность. Такой вариант особенно подходит, когда в самом начале сложно определить, сколько именно времени понадобится на завершение каждого этапа. В этом случае утверждать и согласовывать даты можно будет уже в ходе официальной переписки по завершению каждого предыдущего этапа;

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

Мы подготовили плюс/минус стандартное описание этапов работ с указанием сроков.

№	Этап	Описание этапа	Срок, рабочие дни
1	Проект	Исполнитель создаёт структуру, прототипы интерфейсов Приложения и описание процессов	15 (пятнадцать) дней с момента подписания Заказа и получения согласованных в Заказе Материалов
2	Концепция дизайна	Исполнитель создает дизайн ключевых страниц и элементов Приложения на основании Заказа	5 (пять) дней с момента подписания акта и полной оплаты по этапу 1
3	Дизайн	На основе согласованной концепции дизайна Исполнитель создаёт Дизайн интерфейсов Приложения	25 (двадцать пять) дней с момента подписания акта и полной оплаты по этапу 2
4	Техническое задание	На основе согласованного Дизайна интерфейсов Исполнитель создаёт техническое задание	5 (пять) дней с момента подписания акта и полной оплаты по этапу 3
5	Программирование	На основе согласованного Дизайна Исполнитель разрабатывает Программный код Приложения	40 (сорок) дней с момента подписания акта и полной оплаты по этапу 4
6	Релиз	Создание аккаунтов в маркетплейсах. Публикация Приложения в App Store и Google Play. ASO-оптимизация.	3 (три) дня с момента подписания акта и полной оплаты по этапу 5

Приёмка и расчёты

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

Определение стоимости

Существуют два главных способа определения стоимости разработки мобильного приложения. Первый: оценка стоимости всего проекта согласно ТЗ (технического задания) — грубо говоря, это стоимость за количество единиц работы (например, текстов, страниц приложения и т.д.). Второй: оценка времени сотрудников, которое будет потрачено на задачу. При этом одни разработчики оценивают часы своих сотрудников одинаково, а другие — по-разному (в зависимости от специализации и квалификации).

Оба варианта имеют подводные камни. В первом случае в интересах Исполнителя завысить стоимость разработки мобильного приложения. И даже не потому, что он жадный. Просто точно определить окончательную стоимость в самом начале невозможно и он хочет подстраховаться.

Во втором случае, когда считаются затрачиваемые сотрудниками на каждый этап проекта часы, Заказчик не имеет гарантий, что подрядчик “не накрутит счетчик”, ведь у него нет возможности проверить, сколько же часов было потрачено в реальности. К тому же, пока приложение не будет закончено, проверить результаты каждого отдельного этапа довольно сложно. Приведем пример. Подрядчику заказали разработку двух модулей приложения. Прошло два месяца и он что-то сделал. Хоть Заказчик и может посмотреть и дизайн, и код, но запустить еще нечего. То есть пользу еще он не получил, а заплатить уже надо.

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

Оплата

Оплата полностью зависит от того, какой способ оценки был выбран. Большинство подрядчиков хотят получать оплату часто и регулярно, чтобы быть уверенными в надежности Заказчика, поэтому в нашем образце договора предлагается следующая формулировка:

3.2. Заказчик оплачивает каждый этап работ в следующем порядке:

3.2.1 До начала работ по этапу — 50% от стоимости этапа (предоплата).

3.2.2 В течение 5 (пяти) рабочих дней с даты подписания акта Работ по этапу — оставшиеся 50% от стоимости этапа.

Гарантийные обязательства

Представим, что мобильное приложение — это пылесос. У него есть функции и характеристики: наличие/отсутствие мойки, объём мешка, сила всасывания, количество насадок, габариты, вес и т.д. Если функции не выполняются, характеристики не соответствуют заявленным производителем, и вы не сделали ничего противоречащего инструкции, в указанный в гарантии срок вы можете потребовать возврата потраченных на него денег, нового пылесоса или ремонта первого.

С мобильным приложением подход такой же. По сути это тот же продукт, который должен обладать конкретными функциями. Если они не выполняются так, как должны — приложение нужно доделывать/переделывать.

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

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

Не устаем повторять, что договор должен быть взаимовыгодным, а значит, интересы Заказчика должны быть учтены и в этом случае. Если Исполнитель отказывается устранять проблемы в приложении, Заказчик может потребовать с него пени.

Интеллектуальная собственность

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

Для примера мы взяли довольно распространенный модуль «Калькулятор»:

5.1. Исполнитель является правообладателем модуля «Калькулятор» (далее — Калькулятор), который будет использоваться в Приложении.

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

Прочие условия

Как и следует из названия, в этом разделе прописываются любые условия, которые необходимо зафиксировать, но они не вписываются в другие разделы договора.

Очень часто сюда включают лишние фразы, которые и так подразумевают нормы ГК РФ. Например: «Приложения к Договору являются его неотъемлемой частью». А как иначе? Конечно, являются, это ведь прописано в Гражданском Кодексе. Прописывать здесь стоит только нюансы, являющиеся предметом договоренности сторон.

Например, если мобильное приложение предназначено для доставки еды из ресторана, можно прописать такой нюанс:

1. Заказчик в течение 3 (трёх) дней с момента заключения Заказа должен предоставить следующие Материалы: меню ресторана для загрузки в Приложение.

Также в этом разделе стоит обозначить официальных представителей сторон.

Приложение №2. Задание

Стороны должны изначально прийти к согласию, какой вид Задания будет использоваться.

Выбор предстоит сделать из двух следующих вариантов:

• Задание, в котором Заказчик самостоятельно прописывает, что именно он хочет. Оно может быть любым: коротким или длинным, подробным или тезисным. Важно иметь в виду, что именно Задание будет основанием для создания приложения, а по статистике 99% заказчиков не могут сделать его качественно, что чревато различными проблемами;

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

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

Шаблон договора

Ура! Мы закончили свои пояснения. Как и обещали, прикрепляем образец договора на мобильную разработку + приложений к нему: https://docs.google.com/document/d/1omgD65fZE9dSFSOHO94M5m2bpO8p3dTT/edit#heading=h.gjdgxs.

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

Возможно, вам также будет полезен образец коммерческого предложения и шаблон брифа на мобильную разработку с нашими пояснениями о правилах их составления.

Удачи в бизнесе!