Как выбрать компанию по разработке ПО в Стамбуле и Турции

Выбирая компанию по разработке ПО в Стамбуле или в целом в Турции, полезно спрашивать не «кто лучший?», а «кто сдаст проект так, чтобы результат можно было проверить, и оставит код мне?». Короткий список составляется по четырём признакам: работающие продукты, которые можно открыть, и клиенты, с которыми можно поговорить; доступ к репозиторию и исходному коду с первого дня; письменный процесс и договор; определённая поддержка после запуска. Чек-лист и таблица оценки ниже помогут сравнить трёх-четырёх кандидатов по одним и тем же критериям.

На что смотреть в первую очередь при выборе компании по разработке ПО?

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

1. Соответствие задаче: выпускала ли компания в продакшен что-то похожее на ваш проект: веб-платформу, мобильное приложение, MVP, интеграцию?
2. Проверяемость: работают ли показанные проекты сегодня и можно ли поговорить с их заказчиками?
3. Техническая прозрачность: где хранится код, кто его проверяет и как он попадает в продакшен?
4. Коммерческие условия: зафиксированы ли письменно модель договора, права на результат, защита данных и поддержка?
5. Коммуникация: с кем именно вы будете общаться, как часто и на каком языке?

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

Как проверить портфолио и рекомендации?

Портфолио должно быть доказательством, а не галереей скриншотов. По каждому кейсу выясните: работает ли продукт сегодня, что именно делала компания (дизайн, бэкенд или всё целиком), какую задачу решали и как измеряли результат. Если заявлено, что приложение сделано «под ключ», скачайте его и попользуйтесь. Медленные экраны, падения или контент, который не обновлялся месяцами, скажут больше, чем страница кейса.

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

• Уложился ли проект в сроки и объём? Если нет, когда и как компания об этом сообщила?
• Как обрабатывались изменения объёма работ? Были ли неожиданные счета?
• Как быстро реагировали на ошибки после запуска?
• Стали бы вы работать с ними снова?

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

Как оценить технический уровень, не будучи инженером?

Попросите рассказать о процессе и обратите внимание, насколько конкретны ответы. Зрелая команда объясняет следующие вещи с названиями инструментов и примерами, а не общими словами.

• Доступ к репозиторию и владение кодом: хранится ли код с первого дня в вашем аккаунте GitHub, GitLab или Bitbucket, или его передадут архивом в конце? Правильный ответ: репозиторий, в котором видна вся история коммитов.
• Code review: проверяет ли каждое изменение другой разработчик перед слиянием? Доказательство: история pull request.
• CI/CD: тесты, проверка типов и выкладка автоматизированы или кто-то вручную копирует файлы на сервер?
• Тесты: какие сценарии покрыты автотестами? Не каждая строка нуждается в тесте, но оплата, вход и права доступа должны быть покрыты.
• Окружения: есть ли тестовая среда (staging), где изменения видны до выхода в продакшен?
• Архитектурные решения: могут ли они письменно обосновать выбор технологий? О долгосрочных последствиях таких решений мы писали в статье о проектировании масштабируемой и устойчивой архитектуры.

Почему прозрачность процесса так важна?

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

• Короткие итерации: разбита ли работа на спринты по одной-две недели и показывают ли в конце каждого что-то работающее?
• Демо: видите ли вы прогресс в виде экранов, по которым можно кликать в тестовой среде, а не процентов на слайде?
• Отчётность: регулярно ли и письменно ли сообщают о сделанной работе, затраченных часах и открытых рисках?
• Трекинг задач: можете ли вы сами видеть статус работ в Jira, Linear, Trello или похожем инструменте?

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

Фиксированная цена или Time & Material?

Обе модели работают, если применять их к месту. Проблемы начинаются, когда размытый объём получает фиксированную цену или когда открытый T&M-контракт идёт без контроля.

Практичный вариант: провести анализ и формирование объёма отдельным этапом с фиксированной оплатой, а разработку продолжать либо по фиксированной цене на уже ясный объём, либо в формате T&M с потолком бюджета. Так снижаются риски обеих моделей.

Кому должны принадлежать исходный код и права на результат?

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

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

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

Как оценить защиту данных и безопасность?

Если ваше ПО обрабатывает персональные данные жителей Турции, разработчик обычно выступает обработчиком данных, и обязанности по турецкому закону № 6698 о защите персональных данных (KVKK) должны быть отражены в договоре. Официальные разъяснения публикует Управление по защите персональных данных Турции. Если пользователи находятся в других странах, учитывайте и их законодательство, например требования о локализации данных. Спросите подрядчика:

• Кто и с какими правами получит доступ к боевым данным? Будут ли реальные данные в средах разработки и тестирования?
• Хранятся ли пароли, API-ключи и прочие секреты вне репозитория и в защищённом месте?
• У какого провайдера и в какой стране будут размещены данные? Есть ли трансграничная передача?
• Как устроены разграничение доступа, логирование и резервное копирование, что происходит при инциденте?
• Есть ли в договоре пункты о конфиденциальности и обработке данных?

Что должны покрывать поддержка после запуска и SLA?

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

• Какой срок поддержки после запуска включён и что он покрывает: исправление ошибок, мелкие доработки?
• Каково время реакции (SLA) на критическую ошибку и к кому обращаться в нерабочее время?
• Что входит в договор сопровождения: обновление зависимостей, патчи безопасности, мониторинг серверов?
• Кто отвечает за совместимость мобильного приложения с новыми версиями iOS и Android? Почему сложнее всего именно распространение, мы объясняем на странице разработки мобильных приложений.

Как проверить стабильность команды и коммуникацию?

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

О коммуникации договоритесь заранее: ритм встреч, общий канал (Slack, Teams или почта), скорость ответа на вопросы и язык документации. Если вы работаете с турецкой командой из другой страны, убедитесь, что на вашем языке или на английском свободно общаются те, с кем вы будете говорить каждый день, а не только менеджер по продажам.

Какие тревожные сигналы должны вас остановить?

• Цена заметно ниже других предложений: разницу обычно закрывают за счёт тестов, code review, документации или поддержки, а платите за это вы позже.
• Нет письменного объёма работ: «сделаем, как договорились» при споре не оставляет вам ничего.
• Нет доступа к репозиторию: если код нельзя увидеть до конца проекта, вы не знаете, что пишется.
• «Всё будет готово за две недели»: жёсткий срок, названный до обсуждения требований, это рекламная фраза, а не оценка.
• «Да» на любой вопрос: хорошая команда спорит, предлагает сократить объём и иногда говорит «сейчас вам это не нужно».
• Инфраструктура на имя подрядчика: серверы, домен или аккаунт в магазине приложений открываются не на вас.
• Зависимость от одного человека: все знания у одного разработчика, ничего не записано.

Таблица оценки компаний по разработке ПО

Поставьте каждому кандидату оценку от 1 до 5 по каждому критерию, умножьте на вес и сложите. Веса можно менять под свой проект; ниже разумная отправная точка для большинства веб- и мобильных проектов.

Если кандидат получил 1 хотя бы по одной строке, пересмотрите его даже при высокой сумме. Владение кодом и письменный объём работ особенно трудно исправить потом.

Какие вопросы задать на первой встрече?

1. Можете показать работающий проект, похожий на наш, и дать поговорить с этим клиентом?
2. Кто будет работать над проектом и кто технический лид?
3. В каком репозитории будет код и когда у нас появится доступ?
4. Как изменение попадает в продакшен и какие шаги автоматизированы?
5. Как часто и в какой форме мы будем видеть прогресс?
6. Как рассчитывается влияние изменений объёма на сроки и бюджет?
7. Какая поддержка включена после запуска и как устроено сопровождение потом?
8. Где вы видите главный риск этого проекта?

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

Какие практические преимущества даёт команда из Стамбула?

Местоположение само по себе не критерий качества, но кое-что упрощает:

• Часовой пояс: Стамбул круглый год живёт по UTC+3, как и Москва, поэтому рабочие часы совпадают и вопросы решаются в тот же день.
• Очные воркшопы: одна-две встречи за одним столом на этапе анализа могут заменить недели переписки; Стамбул хорошо связан прямыми рейсами со многими городами региона.
• Договор и счета для турецких компаний: если ваша компания зарегистрирована в Турции, договор составляется на турецком по местному праву, а счета выставляются по местным правилам, без валютных операций.
• Знание KVKK: местные команды регулярно работают с требованиями KVKK, электронными счетами-фактурами и местными платёжными интеграциями.

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

Как Detartech отвечает на эти критерии?

Мы разрабатываем веб-, мобильные и MVP-проекты из офиса в районе Умрание, Стамбул. Наши ответы на чек-лист выше:

• Работаем двухнедельными спринтами и в конце каждого показываем работающую версию.
• Каждое изменение перед слиянием проверяет другой разработчик, тесты и выкладка идут через автоматизированный CI/CD.
• Репозиторий со всей историей находится в вашем аккаунте, а серверы, базы данных и домены настраиваются на аккаунтах, открытых на ваше имя. Состав передачи описан на странице веб-разработки.
• 30 дней поддержки после запуска входят в сдачу проекта.
• В проектах разработки MVP мы передаём технический долг в виде письменной записки.

Работающие проекты можно посмотреть на странице историй успеха; например, Lextum AI (управление юридическими документами с помощью ИИ) и Welldone (управление промышленной прачечной) показывают, как мы работаем.

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

Часто задаваемые вопросы

Какая компания по разработке ПО в Стамбуле лучшая?

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

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

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

Как оценить компетенции подрядчика без технического образования?

Попросите доступ к репозиторию, историю pull request и code review, и пусть вам по шагам объяснят, как изменение попадает в продакшен. Конкретные ответы с названиями инструментов и примерами хороший знак. При необходимости отдайте предложение и код на проверку независимому техническому консультанту.

Что надёжнее: фиксированная цена или T&M?

Если объём ясен и стабилен, фиксированная цена даёт предсказуемый бюджет. Если продукт будет формироваться по мере обратной связи от пользователей, T&M гибче, но требует отчётов по спринтам и потолка бюджета. Отдельный этап анализа снижает риски обеих моделей.

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

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

Что будет, если я захочу сменить подрядчика?

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