Маркетплейс

Сколько будет стоит разработка

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

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

Но можно рассчитать примерный бюджет.

Как я упоминал выше, разработка маркетплейса может быть коробочной или кастомной. На рынке существует большое количество всевозможных коробочных вариантов маркетплейсов. Разработка базового варианта может стоить до миллиона рублей, а срок выполнения — 1,5–2 месяца.

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

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

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

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

Разработка этого модуля занимает от 40 до 80 часов.

Модуль управления данными и ролями

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

Разработка этого модуля занимает от 60 до 120 часов.

Модуль администрирования

Просмотр и управление всеми данными в системе, просмотр транзакций, разрешение споров, аналитика и статистика.

Разработка этого модуля занимает от 150 до 300 часов.

Модуль поиска

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

Разработка этого модуля занимает от 80 до 200 часов.

Модуль управления товарами или услугами

Добавление, редактирование и удаление товаров и услуг с различным набором полей. Категоризация данных. Управление состоянием товаров и услуг.

Разработка этого модуля занимает от 80 до 200 часов.

Модуль социального взаимодействия

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

Разработка этого модуля занимает от 150 до 300 часов.

Модуль оплаты

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

Разработка этого модуля занимает от 80 до 200 часов.

Основные ошибки при создании маркетплейса

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

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

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

Давайте рассмотрим наиболее часто встречающиеся ошибки построения маркетплейсов.

Неправильно выбранные инструменты и команда

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

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

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

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

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

В результате нам пришлось полностью переписать некоторые части приложения.

Придумывают фичи в ходе разработки

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

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