Реальный вопрос: «Сколько стоит сделать свой Booking?»

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

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

Клонирование или создание конкурента?

Eсли вы хотите создать проект, похожий на Facebook, Booking, Twitch или Reddit, то не нужно делать клона.

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

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

Во-вторых, скорее всего, агентства не захотят с вами работать. Ведь, по сути, это воровство идей.

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

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

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

Масштаб

Нужно понимать, что часто цена зависит от масштаба проекта.

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

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

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

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

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

Можно очень быстро и очень дёшево сделать условный “Reddit” с примерно такими же возможностями, как и у оригинального. Только он не выдержит большого количества посетителей и не будет иметь возможности для масштабирования.

Архитектура

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

И это касалось всех блюд.

Совершенно логичный вывод в такой ситуации — заболеет шеф-повар, и бизнес остановится.

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

Полностью отсутствуют стандарты, документация, регламенты.

Ведь некогда этим всем заниматься. Нужно работать!

Что будет дальше? Ну, в какой-то момент ваш технический директор заболеет или ему это надоест. И в коде больше никто не сможет разобраться.

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

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

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

Точно такой же, как если повар в ресторане не знает, сколько оливок класть в пиццу, и не может это где-то прочитать. А сразу идёт к шеф-повару.

Разработка

Самым логичным вариантом будет создание минимальной версии продукта. Для того чтобы проверить гипотезу, показать её инвесторам и убедиться, что этот продукт востребован рынком.

MVP (minimum viable product) — это минимально жизнеспособный продукт. Продукт, который обладает минимальным, но достаточным набором функций для удовлетворения первых потребителей.

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

MVP проекта

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

1. Proof-of-concept, проверка идеи.
   Данный продукт зачастую отличается базовым дизайном или его практическим отсутствием, содержит очень ограниченную функциональность, которая является ядром сервиса. Этот тип MVP в основном применяется к системам, обладающим сложным алгоритмом работы или высоко рискованной, с точки зрения вложения средств, идеей. Пользоваться таким продуктом в реальной жизни вряд ли получится, это больше экспериментальный режим.
2. Запуск проекта в закрытом режиме, для ограниченной аудитории, по приглашениям.
   Такой запуск осуществляется в основном для демонстрация партнёрам и инвесторам, текущим или потенциальным, для привлечения дополнительных средств на развитие проекта. Или же для сбора обратной связи от первых адептов проекта и миноритарных инвесторов.
   Такой проект зачастую обладает более чем ядровой функциональностью, но и возможностями, которые уже позволяют пользоваться проектом в реальной жизни.
3. Запуск проекта в открытом режиме, для широкой аудитории.
   Обычно это уже полноценный релиз, который подразумевает больший, чем во втором пункте, набор функциональности, отлаженность процессов и продуманность UI/UX.

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

Роли и функциональность

Можно разделить пользователей сайта на три большие группы.

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

Общая функциональность

Сервис уведомлений (email, SMS)

В данном проекте сервис уведомлений используется для:

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

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

Разработку данной функциональности MVP можно оценить в 20 — 40 часов.

Связь с администрацией сервиса

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

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

Разработку данной функциональности MVP можно оценить в 20 — 40 часов.

Путешественники

Регистрация и аутентификация (почта + соцсети)

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

Разработку данной функциональности MVP можно оценить в 40 — 80 часов.

Просмотр, поиск, фильтрация и сортировка объектов

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

Разработку данной функциональности MVP можно оценить в 200 — 400 часов.

Просмотр информации об объекте и доступных номерах

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

Разработку данной функциональности MVP можно оценить в 80 — 160 часов.

Бронирование

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

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

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

Разработку данной функциональности MVP можно оценить в 40 — 120 часов.

Личный кабинет

Путешественники могут в своем личном кабинете:

• просмотреть все бронирования, осуществлённые ими, как текущие, так и прошедшие, а также изменить статус бронирования;
• просмотреть и отредактировать информацию, связанную с их профилем на сайте (персональные данные, почту, пароль).

Разработку данной функциональности MVP можно оценить в 40 — 80 часов.

Отзывы и рейтинг

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

В дальнейшем после релиза MVP данную функциональность можно будет расширить и сделать более кастомизированной.

Разработку данной функциональности MVP можно оценить в 40 — 80 часов.

Собственники

Регистрация и аутентификация собственников посредством почты

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

Разработку данной функциональности MVP можно оценить в 20 — 40 часов.

Просмотр и редактирование профиля

Собственники, как и путешественники, могут просмотреть и отредактировать информацию о себе.

Разработку данной функциональности MVP можно оценить в 20 — 40 часов.

Управление собственностью и бронированиями

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

Собственникам в данном разделе предоставляются следующие возможности:

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

Разработку данной функциональности MVP можно оценить в 200 — 400 часов.

Администраторы сервиса

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

• Управление пользователями всех ролей.
• Управление странами и городами.
• Управление объектами.
• Управление номерным фондом.
• Управление тарифами.
• Управление услугами.
• Управление бронированиями.
• Управлениями отзывами.
• Просмотр статистики по проекту.

Разработку этого раздела администратора можно оценить в 80 — 320 часов.

Стоимость MVP

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

Цена и сроки

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

Соответственно, на разработку MVP такого проекта у вас уйдёт от 1,6 млн ₽ до 3,6 млн ₽.

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

Давайте будем считать, что в среднем мы сможем поставить трёх программистов, которые будут работать одновременно. В таком случае разработка займёт два месяца, если это будут 800 часов и 4 месяца или если это будут 1800 часов.

Жизнь после MVP

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

• Многоязычность.
• Платежи и выплаты:
• оплата бронирования;
• вывод средств собственниками;
• мультивалютность.
• Программы лояльности.
• Компании-собственники.
• Новостные рассылки.
• Акции, скидки, купоны.
• Разработка API для взаимодействия с внешними системами, интеграция с системами управления отелями.
• Расширение возможностей администраторов управления системой и её содержимым.
• Расширение системы рейтинга.
• Расширение возможностей обратной связи.
• Различные способы монетизации сервиса.

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

Вывод

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

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

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.