Как выбрать подрядчика на разработку Web и Mobile в 2026 году: 12 вопросов для ЛПР

Hola, Amigos! На связи Ярослав Ясаков, Head of PMO Amiga.

Выбор подрядчика на разработку — тот случай, когда низкая цена легко превращается в самый дорогой вариант.

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

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

Я собрал 12 вопросов, которые помогают понять, с кем вы действительно собираетесь делать продукт.

1. Делали ли вы что-то похожее?

Не «работали ли вы с крупными клиентами», не «сколько лет на рынке» и не «сколько проектов в портфолио». Это всё мало что говорит о конкретной задаче.

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

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

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

2. Кто конкретно будет делать мой проект?

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

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

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

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

3. Как вы будете делать проект?

Мне всегда подозрительны ответы в духе: «Сделаем за три месяца». Хорошо. А что произойдёт в первый день? Что будет через месяц? Когда появится первый рабочий результат? В какой момент заказчик сможет его посмотреть?

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

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

4. Что именно вы называете аналитикой?

«Сначала сделаем аналитику» — ещё ничего не значит. Важно понять, что конкретно будет сделано на этом этапе. Разберутся ли специалисты в бизнес-задаче? Опишут пользовательские сценарии? Найдут противоречия в требованиях? Проработают интеграции? Зафиксируют ограничения?

И главное — что останется у вас после аналитики. Хорошая аналитика нужна не ради документа на 200 страниц. Её задача гораздо проще: до разработки разобраться, что именно мы строим и зачем. В Amiga этому этапу уделяем отдельное внимание: подробнее о подходе к системной аналитике рассказываем на странице услуги.

Чем лучше это сделано на старте, тем меньше дорогих переделок потом.

5. Почему ваш проект стоит именно столько?

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

Одна команда говорит 5 млн, другая — 8 млн. При этом первая могла просто не посчитать половину работ. Поэтому смотрите не на итоговую сумму, а внутрь неё. Что входит в оценку? Какие специалисты заложены? Учтены ли аналитика, дизайн, QA, релиз, документация, интеграции? Что будет, если требования изменятся?

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

6. Что будет, если мы не уложимся в срок?

Срок разработки любят писать крупными цифрами: «12 недель», «4 месяца», «до конца квартала». Гораздо полезнее спросить, что произойдёт, если команда отстанет от плана.

Как вы узнаете об этом? Кто сообщит? Есть ли промежуточные контрольные точки? Можно ли сократить объём первой версии? Что произойдёт с бюджетом?

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

7. Как я буду понимать, что проект движется?

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

Где задачи? Как выглядит план? Когда показывают результат? Кто принимает решения? Как фиксируются договорённости?
Лучший способ проверить это ещё до старта — спросить, как будет выглядеть обычная рабочая неделя проекта.

Если ответ сводится к «будем регулярно держать вас в курсе», я бы попросил конкретики.

8. Кому будет принадлежать код?

Это вопрос, который почему-то часто вспоминают уже после разработки. А зря.

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

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

Если хотите глубже разобраться в этом вопросе, отдельно рассказываем, как защитить ИТ-продукт и права на код.

9. Как вы тестируете то, что разработали?

«Конечно, тестируем» — плохой ответ. Лучше спросить, что именно тестируют и когда.

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

QA — это не человек, который в последний день перед запуском пытается найти всё, что не заметили остальные. Тестирование должно идти вместе с разработкой. Иначе ошибки просто становятся дороже.

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

10. А что будет после релиза?

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

Поэтому до старта я бы выяснил:

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

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

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

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

Добавилась новая функция — что происходит со сроками? Меняется бюджет? Можно убрать что-то из первой версии? Кто оценивает влияние изменения на проект?

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

12. Можно ли поговорить с вашими клиентами?

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

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

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

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

Итог

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

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

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

Почему Amiga

В Amiga мы как раз так и работаем: не начинаем разработку с обещания «сделаем быстро и недорого». Сначала разбираемся в задаче, задаём неудобные вопросы, считаем риски и только после этого предлагаем решение и оценку.

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

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

Поэтому если вам сейчас предстоит выбрать подрядчика на разработку, можете задать эти 12 вопросов и нашей команде. Пишите на hello@amiga.ru — расскажем, как подходим к разработке и что можем предложить для вашего проекта.