Рейтинг Рунета

Рейтинг разработчиков мобильных приложений, Информационные и инженерные технологии

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

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

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

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

Методология рейтинга
Коротко о рынке
#Название
Цены

Чем больше в этом столбце значков ₽, тем выше стоимость услуг агентства.

Клиенты

Количество клиентов агентства.

Крупные

Количество крупнейших корпораций, для которых агентство делало проекты

Средний срок

Средний срок работы с клиентом

Обсудить
мой проект

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

Реклама
₽₽⦁⦁2671 год
Реклама
1
Место: 1 3
Балл: 14.96
₽₽₽₽3602 года 4 мес
2
Место: 2 NEW
Балл: 14.20
₽₽₽₽651 год 9 мес
3
Место: 3 2
Балл: 9.82
₽₽₽₽723 года 6 мес
4
Место: 4 NEW
Балл: 8.81
₽₽₽1443 года 11 мес
5
Место: 5 3
Балл: 8.80
₽₽₽₽421 год 5 мес
6
Место: 6 NEW
Балл: 8.47
⦁⦁⦁⦁311 год 3 мес
7
Место: 7 NEW
Балл: 5.57
₽₽₽₽321 год 3 мес
8
Место: 8 NEW
Балл: 5.39
₽₽₽₽303 мес
9
Место: 9 NEW
Балл: 4.41
₽₽₽506 мес
10
Место: 10 7
Балл: 4.10
₽₽₽₽501 год
Реклама
₽₽₽3 1 год 2 мес
11
Место: 11 NEW
Балл: 4.01
⦁⦁⦁⦁311 год 3 мес
12
Место: 12 7
Балл: 2.93
₽₽₽₽301 год 1 мес
13
Место: 13 4
Балл: 2.91
₽₽⦁⦁304 мес
14
Место: 14 3
Балл: 2.72
₽₽⦁⦁711 год 1 мес
15
Место: 15 9
Балл: 2.58
₽₽⦁⦁511 год 9 мес
16
Место: 16 9
Балл: 2.03
₽₽₽₽5110 мес
17
Место: 17 NEW
Балл: 1.82
₽₽₽₽312 года 8 мес
18
Место: 18 NEW
Балл: 1.79
₽₽₽501 год 3 мес
19
Место: 19 9
Балл: 1.78
₽₽₽₽311 год 1 мес
20
Место: 20 12
Балл: 1.48
₽₽⦁⦁302 года 11 мес
Реклама
₽₽₽3 1 год 2 мес
21
Место: 21 9
Балл: 1.47
₽₽₽₽321 год 1 мес
22
Место: 22 8
Балл: 1.36
₽₽⦁⦁401 год 4 мес
23
Место: 23 NEW
Балл: 1.28
₽₽⦁⦁329 мес
24
Место: 24 7
Балл: 1.13
₽₽₽405 мес
25
Место: 25 12
Балл: 1.06
₽₽₽3111 мес
26
Место: 26 NEW
Балл: 0.93
₽₽₽306 мес
27
Место: 27 NEW
Балл: 0.87
₽₽₽302 мес
28
Место: 28 NEW
Балл: 0.85
⦁⦁⦁⦁301 год

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

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

Объемы рынка мобильной разработки

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

Общее количество зарегистрированных в совместной базе Рейтинга Рунета и CMS Magazine компаний-мобильных разработчиков — 610. Общее количество разработанных ими приложений на iOS и Android — 13 229 (из которых 8 250 — на iOS, 4 979 — на Android).

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

Стоимость услуг по разработке приложений

Компании, разрабатывающие приложения, делятся на четыре ценовых сегмента: Нижний ( до 200 000 рублей), Средний (от 200 000 рублей до 500 000 рублей), Верхний (от 500 000 рублей до 1 000 000 рублей) и Премиум (от 1 000 000 рублей и выше). Для того, чтобы выбрать подходящего под финансовые возможности подрядчика, стоит воспользоваться ценовыми срезами рейтинга: Нижний, Средний, Верхний и Премиум.

В среднем заказная разработка приложения обходится в 588 236 рублей, на iOS — 604 729 рублей, на Android — 570 380 рублей.

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

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

  • Москва — 829 408 рублей
  • Санкт-Петербург — 761 977 рублей
  • Новосибирск — 660 000 рублей
  • Ростов-на-Дону — 496 875 рублей
  • Краснодар — 376 406 рублей

Как выбрать мобильного разработчика?

Рейтинг, отзывы клиентов и прямое общение с кандидатами — пожалуй, самые главные инструменты для выбора. На какие именно критерии обращать внимание? Вот список основных:

  • Опыт разработки приложений на нужной ОС
  • Опыт разработки приложений схожей тематики и функционала
  • Временной прогноз на реализацию проекта
  • Ценовая ниша разработчика
  • Победы в отраслевых конкурсах (по необходимости)

Советы от экспертов по разработке мобильных приложений

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

Дмитрий Лемайкин, iOS-лид в Globus IT

Мобильное приложение — это приложение конечного пользователя. Поэтому основные отрасли, которые чаще всего используют мобильную разработку, — это ритейл, индустрия развлечений, контентно-ориентированные компании (аудио, видео, тексты). Однако и те, которые производят ПО, нередко разрабатывают мобильные приложения и привлекают для этого подрядчиков.

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

  • Автоматизация процессов управления персоналом (кадровые процессы, внутрикорпоративная коммуникация, взаимодействие с бухгалтерией и т. д.).
  • Автоматизация работы офисов (мобильные приложения для входа в здание, для бронирования рабочих мест и переговорок, управления принтерами и иной техникой и т. д.).
  • Обертки и дополнения для сервисов крупных компаний, которые пишут ПО. Например, Яндекс или Сбер пишут какие-то сервисы, подрядчики делают к ним МП как для продвижения этих сервисов, так и для их коммерческого использования.
  • Выделение отдельного SDK из существующего приложения для переиспользования как в отдельных продуктах, так и для самостоятельного коммерческого использования. Например, разработка SDK для оплаты товаров в магазине с помощью сканирования лица человека.
  • Интеграция платежных систем. Если у софтверной компании мобильная разработка — непрофильное направление, то им дешевле привлечь сторонних специалистов с опытом для реализации сложных задач, таких как интеграция платежной системы.

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

Но есть и обратный поток, который идет от натива в сторону новых кроссплатформ, — например, Kotlin Multiplatform. Недавно вот появилась новая кроссплатформа SCADE 2.0 на Swift, на которой можно также делать интересные проекты с общей логикой.

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

  • Попытка развивать проект на старом и не всегда хорошо работающем коде, вместо того чтобы разработать новый вариант сервиса;
  • Неумение и/или нежелание слушать команду разработчиков;
  • Директивный подход в управлении сложными техническими проектами;
  • Незаинтересованность в конечном результате со стороны менеджмента.

Каждый отдельный проект — это отдельная история, и складывается она по-разному. Мы же стараемся найти заинтересованного в успехе проекта заказчика и подсказать ему, как мы можем сделать лучше. Для этого разъясняем заказчику последствия принимаемых решений.

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

Николай Николенко, технический директор KODE

С 2013 года мы создаём цифровые продукты для государства и крупного бизнеса в России и Европе. Что мы можем подытожить, исходя из нашего опыта работы с софтверной тематикой:

1. Стек технологий должен «подходить» заказчику

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

Мы стараемся всегда создавать продукт так, чтобы ИТ-команда заказчика (или любой другой вендор) могли его сопровождать после приёмки продукта, для этого предоставляем полную и понятную документацию, современный стек с учётом особенностей заказчика.

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

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

2. Информационная безопасность и инфраструктура — кладезь сюрпризов

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

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

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

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

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

Выводы

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

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

  • Команда разработки должна проектировать сервис, который сможет интегрировать в инфраструктуру заказчика.
  • Стэк разработки должен быть актуальным. Инхаус-команда заказчика должна уметь поддерживать выбранные решения, а при необходимости заказчик в любой момент мог найти на рынке специалистов для доработки и обслуживания системы.
  • Отдел ИБ — наши друзья, которые делают сервис безопасней.
  • Не слепо выполнять ТЗ, а понимать конечную цель продукта.

Другие советы по теме digital-маркетинга для разработки ПО

Заинтересовала компания? Узнайте цены и сроки выполнения вашей задачи