WordPress — отличная система для сайтов, блогов и небольших магазинов. Под неё существуют десятки тысяч плагинов, и кажется, что с их помощью можно собрать что угодно: личные кабинеты, оплату, расписание, тесты, рассылки. Именно так рождается веб-сервис на WordPress — быстро, недорого и на знакомом инструменте. Проблемы начинаются позже, когда сервис должен выдерживать рост.
Ниже — собирательный антикейс. Компания условная, но решения и последствия взяты из проектов, которые приходили к нам на аудит и переработку. Разбираем исходную задачу, ошибки на старте, последствия для бизнеса и то, как нужно было выбирать инструменты.
Онлайн-школа дизайна: несколько курсов, кураторы, домашние задания с проверкой, сертификаты по окончании. Сначала школа работала через мессенджеры и таблицы, но при первой сотне студентов стало ясно, что нужен собственный сервис. Требования звучали так: личный кабинет студента, приём оплат, расписание вебинаров, загрузка домашних заданий, проверка кураторами, прогресс по курсу, рассылки.
Бюджет был ограничен, сроки — сжатые: до старта нового потока оставалось два месяца. Подрядчик, который раньше делал школе сайт, предложил решение: «У вас уже есть сайт на WordPress, добавим плагины для обучения, оплаты и кабинета — всё будет работать через месяц».
Сервис действительно запустили вовремя. Проблемы были заложены в выборе инструментов.
WordPress создавался как система управления контентом: страницы, записи, медиафайлы. Школе же нужна была система с пользователями, ролями, сложными связями между курсами, уроками, заданиями и оценками. Никто не сравнил варианты — выбрали то, что уже было установлено и с чем умел работать подрядчик.
Для обучения — один плагин, для оплаты — второй, для кабинета — третий, для расписания — четвёртый, для рассылок — пятый. Плюс расширения к каждому из них. Итого около двадцати плагинов, которые никогда не проектировались для совместной работы и хранили данные каждый по-своему.
Экраны кабинета получились такими, какими их делали плагины: в разных стилях, с разной логикой кнопок и уведомлений. Студент видел одно меню в разделе курса, другое — в разделе оплаты и третье — в домашних заданиях.
Никто не оценил, как сервис поведёт себя при тысяче студентов, одновременно смотрящих вебинар и загружающих задания. Хостинг выбрали тот же, что для сайта-визитки.
Первый поток прошёл терпимо. Проблемы начались на третьем, когда студентов стало больше семисот:
Итог: вместо развития продукта команда полтора года чинила сервис. Школа потеряла часть студентов из-за технических сбоев и в итоге всё равно пошла на полную переработку — уже без права на простой, с переносом данных тысяч пользователей.
Инструмент выбирают под задачу через два года, а не под задачу через два месяца. Иначе через два года придётся платить за оба решения.
Плагины решают типовые задачи для типовых сайтов. Каждый из них самостоятельно определяет, как хранить данные, как проверять права пользователя и как выглядеть. Когда их двадцать, система превращается в набор чёрных ящиков, связанных между собой хрупкими мостиками. Любое изменение затрагивает сразу несколько ящиков, и предсказать последствия невозможно.
Веб-сервис устроен иначе: у него единая модель данных, единая система ролей и прав, единый интерфейс. Разработка веб-сервисов начинается с проектирования этих основ, а инструменты выбираются уже под них. Мы подробно разбирали похожую историю про сайт в антикейсе о выборе CMS — в сервисах последствия той же ошибки обычно тяжелее.
Правильный путь начинался бы не с вопроса «что добавить к нашему сайту», а с вопроса «какой сервис нам нужен через два года».
Роли пользователей, их сценарии, сущности и связи: курс, поток, урок, задание, проверка, оценка, сертификат. Простая схема на одном листе сразу показывает сложность продукта и отсекает инструменты, которые её не выдержат.
Для онлайн-школы реалистичны три пути: готовая платформа для обучения с доработкой интерфейса, собственная разработка на современном фреймворке или комбинация — готовые сервисы для оплаты, вебинаров и рассылок плюс собственное ядро с кабинетом и логикой обучения. Каждый вариант оценивается по стоимости владения, гибкости и зависимости от внешних поставщиков.
Кабинет студента и рабочее место куратора проектируются как единый продукт: одна навигация, одни паттерны, продуманные уведомления и состояния. Прототип проверяется на студентах и кураторах до начала программирования.
Даже если бюджет ограничен, первая версия должна стоять на правильном фундаменте: единая база данных, нормальная система ролей, хостинг с возможностью масштабирования. Функции можно добавлять постепенно, а фундамент переделывать дорого.
В сервисе школы хранились персональные данные тысяч студентов и история платежей. Каждый из двадцати плагинов — это отдельный код от отдельного автора со своим темпом обновлений. Часть плагинов за полтора года перестала поддерживаться, а администратор откладывал обновления остальных, боясь поломок. Такая система становится лёгкой целью: уязвимость в одном забытом расширении открывает доступ ко всей базе. При собственной разработке или проверенной платформе ответственность за безопасность сосредоточена в одном месте, и её можно контролировать.
Справедливости ради, WordPress и плагины — не зло. Они хорошо подходят в ряде случаев:
Ключевое условие — заранее понимать, где проходит потолок решения, и иметь план перехода, когда проект к нему приблизится.
Вопрос «веб-сервисы цена» в этой истории обманчив. Сборка на плагинах действительно обошлась школе дешевле на старте. Но если сложить полтора года поддержки, потерянных студентов, ручное восстановление данных и итоговую переработку с миграцией, неправильный старт стоил в несколько раз дороже, чем проектирование и разработка на подходящем фундаменте с первого дня.
Хороший ориентир для бюджета — не стоимость первой версии, а стоимость владения сервисом на два–три года, включая развитие и поддержку.
Веб-сервис на WordPress и плагинах — рабочий вариант для проверки гипотезы и простых задач, но опасный фундамент для продукта, который должен расти. Инструменты выбирают после проектирования модели продукта и оценки нагрузки, а не по принципу «что уже установлено». Интерфейс проектируется как единое целое, а не собирается из экранов разных плагинов.
Команда Onebanan начинает любой сервис с модели продукта и карты сценариев, а затем честно сравнивает инструменты — иногда рекомендуя готовую платформу вместо разработки. Если ваш сервис уже упёрся в ограничения плагинов, поможем спланировать переход без остановки работы. Расскажите о задаче сервиса — подскажем, на каком фундаменте его строить.
Как выбор CMS «по совету знакомых» превратил разработку сайта в полтора года переделок — и как нужно было принимать это решение.
Разбираем, из чего складывается бюджет онлайн-сервиса на no-code, какие расходы всплывают через полгода и в какой момент самостоятельная сборка перестаёт быть выгодной.
Честное сравнение двух подходов: где выигрывает веб-приложение, где без мобильного не обойтись и почему иногда правильный ответ — начать с веба.
© Onebanan Digital Agency.