Как оформить разработчика в Узбекистане: трудовой договор, ГПХ или самозанятость

Когда стартап нанимает разработчика, важно выбрать не просто удобный способ оплаты, а правильную юридическую модель сотрудничества. В Узбекистане для этого обычно рассматривают три варианта: трудовой договор, гражданско-правовой договор (ГПХ) и сотрудничество с самозанятым программистом. Главный критерий выбора — не название документа и не желание сэкономить на оформлении, а реальные отношения между компанией и специалистом: кто управляет его работой, какой результат ожидается и насколько самостоятельно он организует свою деятельность.

Главное, что нужно знать:

• Трудовой договор подходит для разработчика, который работает внутри команды, подчиняется руководителю и выполняет постоянную трудовую функцию.
• ГПХ удобен для конкретного проекта, разработки отдельного модуля, интеграции или оказания технических услуг.
• Самозанятый программист может самостоятельно оказывать услуги по разработке и технической поддержке программного обеспечения в рамках разрешенного перечня деятельности.
• Если фактические отношения похожи на трудовые, гражданско-правовой договор не защитит компанию от риска признания отношений трудовыми.

1. Трудовой договор: когда разработчик становится частью команды

Если разработчик ежедневно участвует в работе продукта, получает задачи от CTO или Product Manager, работает по установленному графику и подчиняется внутренним правилам компании, наиболее подходящий вариант — трудовой договор.

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

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

При подготовке договора рекомендую определить:

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

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

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

2. ГПХ: когда нужен конкретный результат, а не штатный сотрудник

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

Например:

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

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

Чтобы договор действительно работал, советую предусмотреть следующие элементы:

Предмет договора. Не ограничивайтесь формулировкой «оказание услуг программиста». Опишите, что именно необходимо разработать, какие функции должны работать и какой результат ожидает заказчик.

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

Сроки и этапы. Разделите крупную разработку на самостоятельные этапы. Для каждого этапа определите результат и порядок его передачи.

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

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

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

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

3. Самозанятый программист: удобный формат для независимого специалиста

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

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

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

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

При сотрудничестве с самозанятым программистом рекомендую проверить:

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

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

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

4. ГПХ или трудовой договор: что выбрать стартапу?

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

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

Представим две ситуации.

Первая: вы нанимаете Backend Developer, который ежедневно работает с командой, участвует в планировании спринтов, получает постоянную зарплату и отчитывается перед CTO. Это типичная ситуация для трудового договора.

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

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

5. Отдельный риск IT-компаний: кому принадлежит исходный код?

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

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

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

Чтобы избежать подобных ситуаций, рекомендую:

• Четко определить, какие результаты разработки создаются в рамках сотрудничества.
• Зафиксировать правовой режим интеллектуальной собственности в соответствующем договоре.
• Установить порядок передачи имущественных прав с учетом применимого законодательства.
• Отдельно урегулировать использование open-source-компонентов и сторонних библиотек.
• Предусмотреть передачу исходного кода, технической документации и необходимых доступов.
• Проверить права на результаты, созданные до начала сотрудничества или с использованием материалов третьих лиц.

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

6. Что сделать на этой неделе: практический чек-лист

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

• [ ] Опишите фактическую модель сотрудничества: постоянная работа в команде или самостоятельное выполнение проекта.
• [ ] Определите, нужен ли компании трудовой договор или гражданско-правовая модель.
• [ ] Если рассматриваете самозанятость, проверьте регистрацию специалиста и действующий перечень разрешенных видов деятельности.
• [ ] Подготовьте техническое задание с измеримыми результатами и критериями приемки.
• [ ] Пропишите стоимость, сроки, порядок оплаты и ответственность сторон.
• [ ] Урегулируйте принадлежность интеллектуальных прав на программный код и документацию.
• [ ] Проверьте конфиденциальность, доступ к репозиториям и правила обработки данных.
• [ ] Проведите юридическую проверку действующих договоров с разработчиками.

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

FAQ: частые вопросы о найме разработчиков

Можно ли нанять программиста по ГПХ на постоянную работу?

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

Может ли самозанятый программист работать с юридическим лицом?

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

Нужно ли подписывать отдельный договор на передачу исходного кода?

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

Что выгоднее стартапу: ГПХ или трудовой договор?

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

Можно ли использовать один договор для всех разработчиков?

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

Заключение

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

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

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

*Материал носит общий информационный характер и не является индивидуальной юридической консультацией.*