Необхідний мінімальний контракт кейс на початковому етапі

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

Все просто. Якщо не оформити правильно права на продукт, то продукту можна з легкістю його позбутися або не правильно обрана схема оптимізації податків, просто з'їсть весь прибуток. Так, і без належного оформлення компанії та її активів, не вийде говорити з інвесторами і «ангелами» про залучення грошей або вдалий екзит. Тому що вони завжди мають величезний штат юристів, який може зарубати будь-яку угоду, не дозволяючи купити «повітря» своєму керівнику.

На етапі зародження і становлення необхідно звернути увагу на наступні моменти: По - перше, це оформлення компанії і співробітників/партнерів, а також розробка схеми роботи. По-друге, створення контракт-кейсу.

У цій статті ми розглянемо, саме ключові моменти контракт - кейса і що необхідно в нього включити, а ось оформлення компанії, розробку схеми роботи і вибір юрисдикції, розглянемо в наступних статтях.

Навіщо мені готувати документи, якщо я можу завантажити їх в інтернеті?

Багато стартаперів-початківців рідко стикалися з необхідністю юридичного оформлення кожного свого кроку. Якщо це вихідці з тех.спеціалістів, то майже всі документи їм вже надали юристи. Але коли відкриваєш свій проект, то розраховувати коштувати тільки на себе, у тебе немає за спиною юридичного відділу і корпоративний юрист вже не підкаже.

Під терміном контракт - кейс, у цій статті ми будемо мати на увазі необхідний мінімум документів. Однак, найчастіше IT компанії діляться на два типи, продуктові та аутсорсові. У них є як загальні, так і різні види документів.

Об'єднує, продуктові та аутсорсові компанії, внутрішні документи. До них належать договори з розробниками, дизайнерами і будь-якими фахівцями, пов'язаними зі створенням інтелектуального продукту. Майте на увазі, що в світі прийнята презумпція авторства, тобто, результатом роботи, володіє автор, а не компанія на яку він працював. Тому, щоб не втягуватися в довгі судові тяжби, необхідно відразу прописати, що вся створена інтелектуальна власність (програмний код, дизайн, контент і т. д.) в рамках виконання трудових або договірних зобов'язань, безумовно і в повному обсязі, переходять роботодавцю/замовнику. Це необхідно оформити як пункт у трудовому договорі або якщо ви працюєте без оформлення трудових відносин, в окремому документі. Але настійно рекомендую, не качайте шаблон з інтернету, краще витратити 50 доларів на створення драфту у юриста. Це дозволить заощадити вам купу часу і нервів.

Також не забуваємо про ще один важливий документ - угода про не розголошення. Адже в IT бізнесі величезну роль грає, хто перший запуститься, якщо у вас ідея на мільярд, то точно не варто ризикувати. Як показує історія Марка Цукерберга, навіть мільярдери крадуть. На практиці сам договір у мене займає всього 8 сторінок, але ось додаток з переліком, що потрапляє під термін «конфіденційної інформації» більше 10. Також з кожним співробітником встановлюється індивідуальний розмір відповідальності, але в середньому це річна зарплата співробітника плюс компенсація прямих збитків і втраченого прибутку. Але все ж у цьому питанні варто знати міру. Більше ніж у людини є, вона не заплатить і суд це розуміє. І як би ви не хотіли, суд не піде на те, щоб робити з людини бомжа.

Зовнішні договори - взагалі заслуговують окремої статті, але ми постараємося лаконічно і по суті описати їх нижче.

Поділимо їх умовно на ті, в яких ми надаємо послуги і там, де послуги надають нам. Основні драфти, які повинні у вас бути, це договори на надання послуг. Зверніть увагу, на той момент, що у випадку, якщо вам пишуть софт або роблять якийсь інтелектуальний продукт, то всі права на нього повинні переходити саме до вас. А не просто право його використовувати, це обов'язково потрібно відобразити в тексті договору. Обов'язково, якомога детальніше описуйте, що саме ви купуєте, взагалі ТЗ повинен бути як додаток.

Якщо вам пишуть софт, то повинен бути обумовлений період на тест і виявлення «багів». Зараз виконавці не гребують зривати і затягувати. Для попередження цього прописуйте чіткі часові рамки з конкретними датами. І тим більше, якщо це поетапна здача проекту. Уточнюйте яким чином передається результат роботи (на фізичному носії або за допомогою онлайн-передачі), та мотивуючу частину: відповідальність, штрафи, тощо. Але не перестарайтеся, оскільки явно завищені штрафи, суд може порізати, як порушення рівності сторін.

Окремо варто згадати СЕО.

Абсолютна більшість виконавців у своїх договорах на просування, вказують, що вони не гарантую результат. Тому наполягайте, на уточненні чітких саксес-метрик, інакше можете позбутися грошей і не отримати результат.

У договорах за якими ви надаєте послуги, ми зараз не про публічні оферти, про них напишемо окрему статтю, головний акцент зробіть на обов'язках замовника. Наприклад, надавати інформацію в зазначений термін і спосіб, затверджувати дизайн, встановивши ліміт на халепу та інше. Все, що вам необхідно від нього, опишіть, а також вкажіть, як саме замовник повинен вам передавати цю інформацію. Пам'ятайте і про ТЗ, воно повинно бути повним і чітким, ніякого двозначності або недомовленості. У будь-яких суперечках - це буде ваш головний аргумент!

Щоб не лити воду, підсумуємо. Перше, у вас під рукою повинні бути трудові договори і договори конфіденційності, які часто підписують просто як з фізичною особою ще на етапі співбесіди, а також мінімум два види договору на надання послуг, де вам надають або де надаєте ви. Друге, скупий платити двічі, якщо не грошима, то часом і нервами, тому - замовте індивідуальні драфти і завжди наполягайте на них. Про причини, я писав у попередній статті. Про подальші юридичні нюанси з якими стикається IT розповімо в наступних статтях.