VR-приложение для бизнеса: сколько стоит и как не слить бюджет на пилот

VR-приложение для бизнеса создают тремя способами: на игровом движке (Unity и аналоги — полный контроль над сценарием, дороже и дольше), через WebXR (запускается прямо в браузере шлема, дешевле, но ограничена графика и офлайн-режим) или на no-code конструкторе (быстрый макет без интеграции с учётными системами). Разработка на движке с подключением к 1С стоит от 500 000 рублей и занимает от двух месяцев.

Кому в Москве VR-приложение окупает бюджет, а кому хватит обычного мобильного

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

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

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

Для остальных задач — каталог, заявки, личный кабинет, интеграция со складом — обычное мобильное приложение решает вопрос быстрее и дешевле. Разработка мобильных приложений остаётся основным путём для большинства B2B-задач, VR добавляют туда, где нужен именно эффект присутствия: обучение, демонстрация, продажа через ощущение масштаба.

Как мебельная компания потеряла выставку из-за дешёвого VR-тура

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

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

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

Три пути разработки: что выбрать под конкретную задачу

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

Если сценарий должен работать без интернета на выставке и подтягивать данные из 1С — берите нативную разработку: только она даёт контроль над офлайн-режимом и производительностью на слабом чипе шлема. Если нужно быстро показать концепцию инвестору или на внутренней встрече без выставочного зала — достаточно WebXR-ссылки, которую открывают в браузере шлема за минуту. No-code конструктор разумен как черновик для обсуждения внутри команды, но собранный там сценарий не стоит показывать клиенту как финальный продукт — переделка на движок начнётся заново.

Кто нужен в команде, чтобы проект не встал на середине

VR-проект нельзя закрыть силами одного мобильного разработчика, даже опытного. Нужен 3D-художник, который умеет не рисовать модель, а урезать её под лимиты автономного шлема. Нужен инженер, который знает конкретный SDK устройства и особенности отслеживания движений именно на нём — тот же код для одного шлема не всегда переносится на другой без правок. Для сценариев с данными нужен разработчик, который уже подключал мобильные и веб-приложения к 1С и понимает, как выгружать остатки и цены без нагрузки на боевую базу. И отдельно — тестировщик, который наденет шлем и походит в нём минимум полчаса, а не проверит сцену по видеозаписи с экрана.

Как проходит проект: от сценария до шлема на стенде

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

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

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

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

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

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

Сколько стоит и когда деньги возвращаются

Нативная разработка VR-приложения с подключением к 1С у нас стоит от 500 000 рублей — сумма растёт вместе со сложностью сценария и количеством уникальных 3D-объектов. Точные условия смотреть удобнее на странице цены и тарифы.

Если бюджет на полноценный VR пока не заложен, часть тех же задач закрывает AR прямо в мобильном приложении — камера смартфона вместо шлема, тот же 3D-каталог, но без отдельного устройства на руках у клиента. Это не замена VR-тренажёру для сложной техники безопасности, но рабочий первый шаг для витрины товара.

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

Что чаще всего портит проект ещё до запуска

Бюджет чаще утекает не на саму разработку, а на переделку из-за трёх решений, принятых в начале. Первое — тестировать сценарий только на компьютере разработчика, а не на том шлеме, который поедет к клиенту или на объект. Второе — откладывать интеграцию с учётной системой «на потом», хотя переписывать архитектуру приложения под данные из 1С задним числом дороже, чем спроектировать это сразу. Третье — экономить на плавности движения камеры: резкие повороты и низкий кадр в VR укачивают сильнее, чем на обычном экране, и это не лечится патчем после жалоб пользователей.

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

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

❓ Частые вопросы

Сколько стоит разработка VR-приложения для бизнеса?

Нативная разработка на движке с интеграцией в 1С стоит от 500 000 рублей, срок — от двух месяцев. Итоговая сумма зависит от количества сценариев, 3D-моделей и того, нужна ли синхронизация с учётной системой в реальном времени, а не разовая выгрузка вручную.

Чем WebXR отличается от разработки на Unity?

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

Можно ли подключить VR-приложение к 1С?

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

На каком шлеме тестировать VR-приложение перед показом клиенту?

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

Сколько времени занимает разработка VR-приложения?

Нативный проект с интеграцией занимает от двух месяцев, WebXR-сценарий — от нескольких недель, макет на no-code конструкторе можно собрать за несколько дней. Срок растёт вместе с количеством уникальных 3D-объектов, а итоговую дату фиксируют после согласования сценария и списка моделей.