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

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

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

Рассказываем, как мы «готовим» свои приложения.

«Хочу то же, что у него!» — классика жанра, знакомая всем парам по походам в ресторан.

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

Здесь цена определяется чуть ли не рандомайзером. Часто зависит от уровня фантазии и дальновидности разработчиков. Исключение составят те, у кого был схожий опыт. Например, мы сделали приложение для Fashion House (крупнейший белорусский ритейлер одежды), и теперь к нам начали обращаться фэшн-ритейлеры из России. Мы им со старта уже можем обрисовать, как все должно работать, а не мучить клиента вопросами.

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

Поэтому мой вам совет — ищите тех, у кого в портфолио лежат похожие на ваш проекты.

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

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

Следующие — те, кто приходит в ресторан с длинным списком ограничений: без глютена, без следов арахиса, без лактозы, без сои и т.д. Они же пишут ТЗ на 50 листов, с радостью расписывают содержание каждого экрана. Вроде, куча информации учтена, но задание не отвечает на вопросы: для кого, что там делать, какие плюсы, что будет после. Просто констатация фактов: в каталоге картинка, цена, бренд. А ведь приложение — это намного больше. Поэтому на таких клиентов тоже придется тратить время, чтобы получить недостающие ответы на вопросы.

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

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

Поэтому почти вся подготовительная работа еще на этапе оценки проекта ложится на плечи студии. И она влияет на цену. С этим надо смириться.

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

Кто-то заморочится даже на уровне визуалов для публикации в сторы, напишет интеграционные тесты со сторонними сервисами, настроит базовую аналитику, функциональную панель управления и т.п. А кто-то, даже если увидит нестыковки в ТЗ, все равно сделает так, как написано. Ведь там так написано…

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

Для начала небольшой ликбез. React Native — это платформа для создания мобильных приложений с открытым исходным кодом. Она предназначена для разработки приложений для Android, iOS. То есть код один, но на платформе он компилируется под 2 операционных системы. Значит, вам больше не нужны два разработчика — по одному под каждую платформу. Теперь достаточно одного, который умеет юзать React Native.

Надеюсь, здесь нет «староверов», которые до сих пор считают, что это неполноценная замена. В любом случае, если будет интересно, то мы в “Веб Секрет” готовим кейс, где расскажем, почему сегодня React Native — уже на 100% годный инструмент. А пока давайте продолжим наш гастро-разработческий гайд по формированию цены.

Вернемся ко всеми любимому «два по цене одного». Разработка кроссплатформенных приложений на React Native — это супер круто, так как экономит время и облегчает внедрение новых фич, обеспечивает точную синхронизацию логики между двумя платформами. Но тестировать продукт приходится все равно по-отдельности, т.к. у каждой из платформ есть свои нюансы.

Многие в порыве сэкономить делают приложения сначала только под одну платформу. В таком случае, конечно, цена снижается на процентов 10 (или больше, если вы работаете с компанией, которая не юзает React Native). Но, давайте будем честны, вряд ли вы сильно выиграете от того, что сделаете приложение только под iOS. Ведь тем самым вы просто лишитесь части аудитории.

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

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

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

У каждого из специалистов есть свой рейт (про них я подробно рассказывал в другой статье). А еще свой уровень — Junior, Middle, Senior, который, кстати, влияет на рейт. У наших сотрудников он в среднем составляет 40-45$ в час.

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

Поэтому его стоимость составляет порядка 4000-5000$, а срок выполнения — около месяца. Если клиент не готов интенсивно работать с командой, то процесс работы растягивается на неопределенный срок.

Следующая строчка нашего рецепта приложения — разработка. Команда трудится параллельно над дизайном, написанием кода и серверной логики. Обычно работа начинается с интеграций, например, с платежной системой или 1С. Затем мы разрабатываем панель управления (вам же надо руководить всеми процессами, рассылать пуши, изучать поведение клиентов). А потом, когда согласованы дизайны первых экранов, переходим к основной части серверной логики.

В случае с кулинарией влияет, например, картошка белорусская или американская, стейк из Аргентины или в Украине выращенный. Короче, вы поняли.

При создании приложений отдельная графа затрат — публикация в сторы. Здесь потребуются хорошие картинки, подготовка отдельного аккаунта для Apple (в случае, если приложение требует от пользователей авторизаций), внимательное заполнение всех полей и прохождение модерации. И не дай вам Бог вносить правки — после каждой придется проходить модерацию заново. Короче, вопрос не 5 минут, к сожалению. А значит, и стоимость тоже не 5$.

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

Окей, предположим, вложились. Люди начали активно оставлять отзывы, что-то не работает, чего-то не хватает. Лайк, дизлайк, отписка. Надо что-то делать. А что? Мое любимое: «А все, а надо было раньше».

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

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

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

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

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

Создание продуманной, удобной и доступной навигации требует времени. Конечно, можно все сделать примитивно и быстро. Но пользователям обычно что-то непохожее на привычные telegram/instagram режет глаз. Поэтому вопрос даже не в анимации, как таковой, а в том, как плавно будут происходить переходы, как будут появлятся новые окна.

А еще частой проблемой этого уровня можно назвать желание клиентов сделать современную анимацию с плавностью 60FPS на Android какой-нибудь 6 версии. Сейчас, на минуточку, уже доступна 11. И нас просят сделать не просто что-то заранее устаревшее, а почти невозможное. Ведь технологии постоянно развиваются.

Если вы об этом упомянули в ТЗ, потому что это модно, имейте в виду, что времени на разработку потребуется немало. А если эти требования реально оправданы, то считайте, что вы не просто идете в ногу со временем, а знаете, как вам это «отобьется».

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

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

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

Одно дело пуш, типа «ваш заказ готов», а другое — уведомление рассылки по сегментам пользователей, чтобы каждый из них переходил на нужный экран (привет первому пункту про диплинки).

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

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

Казалось бы, чат и чат. А на самом деле, куча «историй». Галочка о доставке, прочтении, о недоставке. Функции «ответить» и «переслать». Обмен сообщениями в реальном времени, а не диалог, обновляемый раз в 5 секунд. Возможность отправки и просмотра медиа. Предпросмотр ссылок и многое другое. Все это — очевидные вещи, к которым мы привыкли, поэтому никто не задумывается, сколько времени занимает их создание.

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

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

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

В этом проекте мы с нуля делали: дизайн, отдельно приложение для клиентов, отдельно — для ресторанов, настраивали интеграцию с 4 типами терминалов, которыми чаще всего пользуются в заведениях. Создали огромную панель управления, промо сайт, настроили привязку карточки. Бюджет: порядка 60000$. Срок реализации — 3 месяца.

Какой вывод может быть после всей этой графомании? Такой же, как и в начале. Всегда решать вам, делать быстро, просто и дешево или делать качественно и надолго. Мы, как вы поняли, топим за второй вариант, так как совсем не любим доширак.