Как бизнесу выбрать подрядчика на разработку сайта или сервиса

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

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

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

## Почему выбор подрядчика — это не просто покупка услуги

Разработка сайта или сервиса — это не разовая покупка вроде печати визиток или даже создания логотипа. Сайт после запуска не “заканчивается”. У него есть код, административная часть, интеграции, серверная среда, обновления, безопасность, аналитика, SEO, пользовательские сценарии. Всё это живёт и требует внимания.

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

• Технический долг. Если проект сделали наспех, без нормальной структуры кода и без понимания будущего развития, потом любые изменения становятся дорогими. На практике это выглядит так: вы хотите добавить простую функцию, а вам говорят, что сначала нужно “переписать половину проекта”.
• Отсутствие поддержки. После запуска почти всегда всплывают баги, возникают уточнения, нужны обновления CMS, плагинов, библиотек, интеграций с платёжками или CRM. Если подрядчик исчезает или не хочет сопровождать проект, бизнес остаётся один на один с системой, в которой никто не хочет разбираться.
• Неправильная архитектура. Архитектура — это то, как проект устроен внутри. Если она выбрана плохо, сайт нормально работает только в “спокойном режиме”, а при росте трафика, каталога, заказов или количества пользователей начинает тормозить и ломаться.
• Потеря времени на переговоры и переделки. Если подрядчик с самого начала неверно понял задачу, вы будете проходить один и тот же круг несколько раз: объяснение, демонстрация, замечания, переработка, новые замечания. И это выматывает сильнее, чем кажется.

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

## Как подготовиться к выбору подрядчика

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

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

### Сформулируйте задачу максимально конкретно

Фраза “нам нужен сайт” почти ничего не говорит. Совсем другое дело — “нам нужен интернет-магазин одежды, где пользователь может фильтровать товары по размеру и цене, складывать их в корзину и оплачивать заказ через Яндекс.Кассу”. Во втором случае уже понятен тип проекта, пользовательский сценарий, набор функций и даже примерный уровень сложности.

Перед поиском подрядчика полезно честно ответить на несколько вопросов:

• Что именно нужно сделать? Сайт-визитка, корпоративный сайт, интернет-магазин, личный кабинет, внутренний сервис для сотрудников, веб-приложение?
• Для кого это? Кто будет пользоваться продуктом: клиенты, партнёры, сотрудники? Какой ожидается трафик или нагрузка?
• Какие основные функции нужны? Не весь список “мечт”, а 5–10 ключевых возможностей, без которых проект не имеет смысла.
• Когда это должно быть готово? Нужен реальный срок, а не формулировка “как можно быстрее”.
• Какой бюджет вы рассматриваете? Хотя бы вилку. Многие боятся озвучивать бюджет, но на практике это экономит время обеим сторонам. Если подрядчик работает только с проектами от 700 тысяч рублей, а у вас бюджет 150 тысяч, лучше понять это сразу.

Если на эти вопросы сложно ответить, это не катастрофа. Просто тогда разумнее начать не с тендера, а с консультации или предпроектного обсуждения. Нормальный подрядчик обычно готов потратить время на первичное уточнение задачи — это часть профессиональной работы, а не “одолжение”.

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

### Определитесь со сроками и бюджетом

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

Если вам нужен сайт “за две недели”, это не просто короткий срок. Это уже другой режим работы. И он почти всегда дороже.

Ниже — ориентиры по срокам:

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

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

## Где искать подрядчика

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

### Рекомендации от знакомых и коллег

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

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

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

### Портфолио и веб-сайты студий

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

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

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

Из практики: очень часто бизнес смотрит только на внешний вид сайта из портфолио. Это ошибка. Красивый макет ещё не говорит о хорошем UX. UX — это пользовательский опыт, то есть насколько удобно человеку пользоваться сайтом: находить нужное, не путаться в форме, быстро оформлять заказ. Иногда внешне “скромный” сайт продаёт лучше, чем эффектный, но неудобный.

### Фриланс-биржи (Upwork, Freelance.ru, Habr)

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

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

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

### IT-сообщества и форумы

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

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

Как использовать: спрашивайте в профильных Telegram-чатах, на Habr, Reddit и других площадках, где общаются разработчики и владельцы проектов. Анонимность там часто помогает людям говорить честнее, чем в формальных отзывах на сайте компании.

## Как оценить подрядчика

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

### 1. Портфолио и примеры работ

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

На что смотреть:

• Функциональность. Работают ли кнопки, формы, фильтры, корзина? Не ломается ли интерфейс при обычном использовании? Если демонстрационный проект уже выглядит нестабильно, это плохой сигнал.
• Соответствие вашей задаче. Если вам нужен интернет-магазин, полезнее увидеть именно магазин, чем красивый корпоративный сайт. Если нужен SaaS-сервис, ищите примеры сложных интерфейсов и личных кабинетов.
• Количество проектов. Если в портфолио всего 2–3 работы, причины могут быть разными: компания только начала работать, не умеет оформлять кейсы или ей просто нечего показать. Это не автоматический отказ, но повод проверить внимательнее.
• Разнообразие. Хорошо, когда видно, что подрядчик умеет работать с разными типами задач, бюджетами и сферами. Это обычно говорит о гибкости и реальном опыте.

Что проверить на сайте из портфолио:

• Откройте консоль разработчика в браузере (F12). Если там много ошибок JavaScript, это плохой знак. Не каждая ошибка критична, но десятки сообщений в консоли обычно говорят о слабом контроле качества.
• Проверьте скорость через Google PageSpeed Insights. Это не абсолютный приговор, но хороший индикатор. Если сайт медленный, возможно, он плохо оптимизирован по изображениям, скриптам или серверной части.
• Откройте проект с телефона. Адаптивная вёрстка — то есть корректное отображение на мобильных устройствах — сегодня обязательна. Если сайт на телефоне “едет”, это уже вопрос к базовому качеству.

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

### 2. Опыт в вашей нише

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

Почему это важно? Потому что в каждой нише есть свои типовые сценарии, ограничения и ожидания пользователей. Например, в медицине важны структура услуг, запись на приём, доверие и аккуратная работа с персональными данными. В интернет-магазине — фильтрация, карточки товаров, корзина, оплата, доставка, остатки. В корпоративном b2b-сайте — логика заявок, каталог решений, интеграции с CRM.

Спросите подрядчика прямо: “Вы делали проекты в нашей сфере? Какие были задачи? С какими сложностями столкнулись?”

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

### 3. Технический стек

Технический стек — это набор технологий, на которых строится проект: например, React, Node.js, PHP, Laravel, PostgreSQL, Docker, WordPress и так далее. Для владельца бизнеса это может звучать слишком технически, но хотя бы на базовом уровне понимать этот вопрос полезно.

Почему это важно:

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

Как проверить:

• Спросите, на каких технологиях будет сделан проект.
• Попросите объяснить выбор простым языком: почему именно этот стек подходит под вашу задачу.
• Если есть доступ к коду или техническому описанию, посмотрите, насколько всё структурировано и читаемо.

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

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

### 4. Отзывы и рекомендации

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

Что делать:

• Попросите контакты 2–3 клиентов, которые уже работали с этим подрядчиком.
• Если возможно, созвонитесь с ними и задайте несколько прямых вопросов.
• Посмотрите отзывы на независимых площадках: Яндекс.Карты, 2GIS, Google, Trustpilot и аналогах.

Какие вопросы реально полезно задавать:

• Остались ли вы довольны результатом?
• Были ли задержки по срокам?
• Как подрядчик реагировал на правки и проблемы?
• Была ли поддержка после запуска?
• Начали бы вы с ними новый проект повторно?

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

### 5. Коммуникация и понимание задачи

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

Как проверить это на первой встрече:

• Расскажите о задаче и посмотрите, какие вопросы задаёт подрядчик. Нормальный специалист уточняет цели, сценарии пользователей, приоритеты, ограничения, бюджет, сроки, интеграции.
• Попросите описать, как он видит решение задачи. Ответ должен быть не абстрактным, а приближённым к вашей реальности.
• Спросите, как будет организован процесс: этапы, согласования, демонстрации, тестирование.
• Отдельно попросите назвать риски. Хороший подрядчик умеет говорить не только “мы всё сделаем”, но и “вот здесь возможны сложности, потому что…”.

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

## Красные флаги: когда не стоит работать с подрядчиком

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

Если вы видите сразу 2–3 таких сигнала, лучше продолжить поиск. В моей практике именно сочетание нескольких мелких тревожных признаков почти всегда потом и превращалось в проблемы.

## Как договориться о условиях работы

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

### Договор

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

В договоре обязательно должны быть:

• Описание работ. Не общая фраза “разработать сайт”, а конкретный перечень: каталог, корзина, личный кабинет, форма заявки, платёжная интеграция и так далее.
• Сроки. Когда должны быть готовы этапы и когда сдаётся весь проект.
• Стоимость. Полная сумма или разбивка по этапам, а также условия оплаты.
• Сроки поддержки. Например, 1–3 месяца бесплатного исправления багов после запуска.
• Права на код. Кому принадлежат исходники, макеты, база данных, домен, доступы. Обычно после полной оплаты всё это должно переходить клиенту.
• Условия расторжения. Что происходит, если одна из сторон прекращает работу.

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

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

### Этапы работы

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

Типичные этапы работы:

1. Дизайн и прототип. Подрядчик показывает структуру и внешний вид будущего сайта. Прототип — это схема страниц и пользовательских сценариев без финального визуала, своего рода “каркас”.
2. Вёрстка. Дизайн переводится в HTML и CSS, то есть превращается в реальные страницы в браузере.
3. Функциональность. Добавляется логика: JavaScript на клиентской стороне, серверная часть, работа форм, личный кабинет и так далее.
4. Интеграция с внешними системами. Подключаются платёжные сервисы, CRM, аналитика, складские системы, доставка.
5. Тестирование. Проверяется корректность работы на разных устройствах, в разных сценариях и браузерах.
6. Запуск. Проект выходит в production, то есть на боевой сервер и реальных пользователей.
7. Поддержка. Исправляются найденные после запуска баги и решаются стартовые технические вопросы.

После каждого этапа должна быть приёмка. Вы смотрите результат, даёте согласование или комментарии на доработку. Это гораздо безопаснее, чем увидеть весь проект впервые в день запуска.

### Система оплаты

Есть несколько распространённых моделей оплаты:

• Полная предоплата. Для заказчика это самый рискованный вариант. Подходит только в очень ограниченных случаях, когда вы давно знаете подрядчика и полностью ему доверяете.
• Авансом + при сдаче. Обычно 30–50% в начале, остальное после завершения проекта. Это распространённый и относительно сбалансированный вариант.
• По этапам. Оплата после завершения каждого этапа. На практике это один из самых безопасных форматов для обеих сторон.
• Помесячно. Удобно для длинных проектов, где работа идёт итерациями. Но тогда нужен понятный отчёт о прогрессе.

Я обычно считаю наиболее разумными варианты “по этапам” или “аванс + оплата после сдачи”. Они дисциплинируют обе стороны и снижают вероятность конфликтов.

## Как работать с подрядчиком во время разработки

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

### Регулярная коммуникация

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

На таких встречах полезно обсуждать:

• Что было сделано за неделю?
• Какие сложности возникли?
• Что запланировано дальше?
• Есть ли вопросы, от которых зависит дальнейшая работа?

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

### Обратная связь

Давайте комментарии по промежуточным результатам сразу, как только их видите. Не оставляйте всё “на потом”. Чем позже обнаруживается проблема, тем дороже исправление. Это особенно заметно на этапах дизайна и структуры страниц: поменять блок в прототипе намного дешевле, чем переписывать готовую вёрстку или бизнес-логику.

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

### Документирование требований

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

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

### Тестирование

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

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

## Что проверить перед запуском

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

### Функциональность

• Все функции работают так, как описано в договоре и требованиях?
• Нет ошибок в консоли браузера?
• Все формы корректно отправляют данные?
• Все ссылки, кнопки и сценарии переходов работают?

Отдельно проверьте “краевые” сценарии: что будет, если пользователь отправит пустую форму, введёт неправильный email, нажмёт “назад”, откроет сайт на старом телефоне. Именно на таких местах часто всплывают ошибки.

### Производительность

• Сайт загружается быстро — в идеале до 3 секунд на обычном интернете?
• Изображения оптимизированы?
• Код минифицирован?

Минификация — это уменьшение размера файлов CSS и JavaScript за счёт удаления лишних пробелов, комментариев и служебных символов. Для пользователя это незаметно, но сайт работает быстрее. В реальной работе медленная загрузка часто связана не с “плохим сервером”, а с банально неужатыми картинками и тяжёлыми скриптами.

### Безопасность

• Пароли, токены и ключи не лежат в открытом коде?
• Используется HTTPS?
• Формы защищены от спама — CAPTCHA или аналогичным способом?

HTTPS — это защищённое соединение между пользователем и сайтом. Сейчас это не дополнительная опция, а базовый стандарт. Если сайт работает без HTTPS, это плохо и для безопасности, и для доверия пользователей, и для SEO.

### Мобильная версия

• Сайт корректно выглядит на телефоне?
• Все функции работают на мобильных устройствах?
• Текст легко читается, а кнопки удобно нажимать?

На практике многие сайты проверяют на “своём iPhone” или “своём Android”, но этого мало. Если есть возможность, протестируйте хотя бы на нескольких устройствах и с разными размерами экрана. Адаптивная вёрстка — это не только вопрос красоты, но и конверсии: если человеку неудобно нажимать кнопки, он просто уйдёт.

### SEO

• Заполнены заголовки и описания страниц?
• Сайт добавлен в Google Search Console и Яндекс.Вебмастер?
• Создана карта сайта sitemap.xml?

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

### Аналитика

• Подключены Google Analytics или Яндекс.Метрика?
• Настроено отслеживание важных событий: покупки, регистрации, отправки форм, клики по ключевым кнопкам?

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

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

## Поддержка после запуска

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

### Гарантийный период

Обычно подрядчик исправляет баги в течение 1–3 месяцев после запуска. Этот срок должен быть закреплён в договоре. Важно разделять баги и новые пожелания. Если функция работает не так, как была согласована, это баг и его должны исправить бесплатно. Если вы решили добавить новую возможность, это уже отдельная работа.

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

### Техническая поддержка

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

• Стоимость часа поддержки. В исходной статье приведён ориентир: обычно это 50–150% от стоимости разработки в час.
• Время отклика. За сколько подрядчик отвечает на запрос? И за сколько берётся за критичный баг?
• Каналы связи. Email, Telegram, Slack или другой рабочий канал.

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

### Обновления и развитие

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

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

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

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

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

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

## Типичные ошибки при выборе подрядчика

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

### 1. Выбирают только по цене

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

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

### 2. Не уточняют требования

Если задача описана размыто, подрядчик почти неизбежно интерпретирует её по-своему. А потом выяснится, что вы ожидали один результат, а получили другой — формально “по ТЗ”, но не по смыслу.

Лучше потратить время в начале и уточнить требования, чем потом тратить недели на переделки.

### 3. Не смотрят портфолио

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

Портфолио нужно смотреть обязательно, причём не формально, а внимательно.

### 4. Не проверяют ссылки

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

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

### 5. Не договариваются о деталях

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

Все важные условия нужно фиксировать письменно.

### 6. Не общаются регулярно

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

Смотрите промежуточные результаты и не бойтесь задавать вопросы по ходу работы.

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

Вопрос: Сколько должен стоить сайт?

Ответ: Зависит от сложности. Сайт-визитка обычно стоит 50–150 тысяч рублей. Интернет-магазин — 150–500 тысяч. Сложный сервис — от 500 тысяч и выше. Это ориентировочные цены для России. За рубежом стоимость обычно выше. Важно понимать, что цена зависит не только от типа сайта, но и от состава команды, глубины проработки, дизайна, интеграций и поддержки.

Вопрос: Как часто нужна поддержка?

Ответ: Зависит от типа проекта. Статический сайт-визитка может долго работать почти без вмешательства. А интернет-магазину или сервису поддержка нужна регулярно: обновления, исправление багов, оптимизация, работа с интеграциями, контроль безопасности.

Вопрос: Что делать, если подрядчик исчезнет?

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

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

Ответ: Глубоко — не обязательно. Но базовое понимание помогает. Полезно знать, что React — популярный фронтенд-фреймворк, HTTPS отвечает за защищённое соединение, PostgreSQL — это система управления базой данных. Даже минимальная техническая грамотность помогает увереннее вести разговор и быстрее замечать сомнительные обещания.

Вопрос: Как проверить, что подрядчик не переплачивает