Проверка до договора

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

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

Редакция APPCODIUM9 минут

1. Начните не с цены, а с одинакового понимания задачи

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

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

2. Проверяйте портфолио по смыслу, а не по количеству картинок

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

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

В нашем портфолио мы отделяем действующий продукт от концептов и прямо описываем состав выполненной работы.

3. Смета должна объяснять, за что вы платите

Хорошая оценка разбита на этапы: аналитика и ТЗ, прототип, дизайн, разработка, интеграции, тестирование, публикация. Для каждого этапа указаны результат и порядок согласования. Это полезнее одной строки «сайт под ключ».

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

4. Узнайте, как принимаются решения и правки

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

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

5. Зафиксируйте доступы, права и передачу проекта

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

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

Шесть вопросов перед выбором

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

Ответы должны быть понятны без знания терминов. Для сравнения с конкретной задачей отправьте описание менеджеру Марии через страницу контактов — до расчета мы уточним состав продукта и ожидаемый результат.

Нужна прозрачная оценка без скрытых этапов?

Описать задачу →