Как выбрать исполнителя веб-приложения для компании?

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

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

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

Сначала проверьте, понимает ли исполнитель задачу компании

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

Хороший исполнитель задаёт, среди прочего, такие вопросы:

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

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

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

Узнайте, как исполнитель работает с неопределённостью

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

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

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

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

Сравнивайте одинаковый первый этап, а не только суммы

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

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

Согласуйте права на код, данные и аккаунты до подписания договора

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

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

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

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

Спросите, как будут проверяться самые важные функции

Фраза «приложение будет протестировано» слишком общая. Контактная форма, импорт счетов и система с ролями, платежами и доступом к данным клиентов требуют разных проверок.

Попросите дать ясные ответы на следующие вопросы:

1. Какие процессы критичны и как они будут проверены?
2. Пройдёт ли приёмка в тестовой среде или другим безопасным способом?
3. Как будут проверены роли, права доступа и чувствительные операции?
4. Кто создаст резервную копию перед изменением и известен ли порядок восстановления?
5. Как пройдёт запуск и проверка сразу после него?
6. Что произойдёт, если запуск не выполнит условия приёмки?
7. Как сообщать об ошибках и кто определяет их срочность?

Безопасность также нужно описывать конкретными требованиями и способом проверки, а не общим обещанием. OWASP ASVS предлагает требования, которые можно использовать при проектировании и проверке безопасности веб-приложений. NIST SSDF описывает безопасные практики разработки, которые можно встроить в используемый процесс работы. Это не значит, что каждый небольшой проект должен внедрить весь стандарт. Глубина контроля должна соответствовать риску, типу данных и последствиям ошибки.

Проверьте коммуникацию на конкретном примере

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

Обратите внимание, делает ли исполнитель следующее:

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

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

Портфолио должно показывать работу, а не только внешний вид

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

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

Наши проекты показывают разные виды сложности:

• 44Islands представляет процесс бронирования и систему, развиваемую по этапам для разных ролей;
• HUB.ITM.PL представляет исторический проект сопоставления данных из разных бухгалтерских программ с форматом EDI++;
• HUB-2-API представляет исторический поток товаров, предложений на eBay.de, заказов и API для трёх клиентов из Франции.

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

Согласуйте передачу и сопровождение ещё до начала проекта

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

Передача может включать:

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

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

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

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

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

Риском является не само различие во мнениях и не необходимость дополнительного анализа. Большая проблема возникает, когда важные вопросы остаются без ответа, а обе стороны считают, что одинаково понимают объём.

Что подготовить к первому разговору с исполнителем?

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

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

Можно воспользоваться бесплатным Конструктором описания проекта. Он проведёт вас по основным вопросам и подготовит упорядоченное резюме для дальнейшего разговора. Инструмент не отправляет проект автоматически и не заменяет анализ большого объёма.

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

Нужна ли готовая техническая спецификация до выбора исполнителя?

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

Кто лучше: фрилансер, небольшая компания или software house?

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

Как сравнить два предложения на приложение с разным объёмом?

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

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

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

Всегда ли нужен платный анализ до оценки?

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

О чём спросить в части тестирования и безопасности?

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

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

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

Должно ли сопровождение приложения входить в тот же договор?

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

Дайте всем исполнителям одинаковую исходную информацию

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

Если вы ищете исполнителя заказного приложения, посмотрите услуги программирования PHP и Laravel от Domin Software. После прочтения описания мы сможем сказать, достаточно ли короткого разговора и небольшого этапа или сначала нужен отдельный анализ. Мы не называем полную цену и срок до понимания объёма, данных, интеграций и способа приёмки.

Источники

• OWASP Application Security Verification Standard, OWASP, стабильная версия 5.0.0 опубликована 30.05.2025, доступ проверен 30.10.2026.
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, опубликовано в феврале 2022 года, доступ проверен 30.10.2026.