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

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

Помните зефирный эксперимент из Стэнфордского университета? Там детям предлагали выбор: одна зефирка сейчас или две, но через 15 минут. Так вот, в случае с разработкой сайта вы в такой же ситуации.

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

Конечно, хочется новый сайт «еще вчера» без раздумываний на перспективу — в такое время живем, какое вообще будущее? Тут повышение НДС в 2026-м как-то пережить надо вообще, а горизонт планирования упрямо сужается до пары месяцев. Это — одна зефирка прямо сейчас.

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

Что выберете?

Погодите отвечать. Давайте сначала разберемся :)

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

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

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

2. Консолидация данных. Вся информация о пользователе (личные данные, история заказов, предпочтения) аккумулируются в одной системе. Так проще настроить единую программу лояльности и использовать маркетинговые инструменты одинаково эффективно и на сайте, и в приложении.

3. Такие проекты проще и дешевле поддерживать. Когда и сайт, и приложение сделаны на одном бэкенде, проще и дешевле вносить любые изменения в оба проекта: у вас одни и те же базы данных, механизмы интеграций, бизнес-процессы (например, оформление заказа и оплата) и часто — одна и та же команда поддержки.

При разрозненной разработке все эти плюсы нивелируются, а бюджеты — раздуваются.

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

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

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

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

Теоретически — да, ведь нет ничего невозможного. Но 90% успеха здесь будет зависеть от того, каков этот старый сайт:

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

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

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

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

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

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

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

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

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

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

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

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

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