WordPress или самописный движок для корпоративного сайта: по каким критериям выбирать?

Если трекинг всего лишь стучится во внешнюю базу и читает оттуда данные, сделать на WordPress отдельный API-эндпоинт и отрендерить всё на фронте нормальной библиотекой — задача на пару дней. Те, кто впаривает самопис, скорее всего, просто продают типовой каркас на MVC под видом уникальной разработки.

Байка про то, что «WordPress небезопасен» — главный козырь всех, кто впаривает самописные движки. Половина мировых медиагигантов и технологических корпораций держат свои блоги и корпоративные порталы именно на нем. Дело не в CMS, а в настройках сервера и прямых руках тех, кто пишет код. А вот закрытая самописная админка вдолгую станет для компании настоящей обузой.

Мы четыре года назад по глупости отдали 120.000 TL за самописную панель. На второй год студия закрылась, на хостинге обновили версию PHP — и всё упало, а на рынке никто в этот код даже лезть не захотел. В итоге потратили еще 45.000 TL и со скрипом переехали на WordPress. Зато расходы на ежегодную поддержку сразу упали в два раза.

Вы у тех, кто предлагает WordPress, спросите: сколько всего плагинов они собираются воткнуть для корпоративных страниц и трекинга? Если скажут «накатим 15-20 штук и норм» — через пару лет сайт превратится в тормозную помойку. Если же они будут пилить чистую тему кодом, а не собирать франкенштейна из плагинов, тогда да, вариант отличный.

Пропишите в договоре жесткое условие: никакой натяжки готовых шаблонов с маркетплейсов, верстка легкой темы с нуля строго под ваши задачи, а количество сторонних плагинов — максимум 4-5 штук. Если подрядчик на это подписывается, можно смело соглашаться на 55.000 TL.

А если на WordPress одновременно зайдут человек 500 и начнут пробивать номера, сайт не ляжет? Неужели у самописного кода нет вообще никакого выигрыша по скорости и нагрузке на сервер? Интересен этот момент.

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

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

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

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

Интересно, есть ли те, кто делает иначе.

Я столкнулся с тем же два года назад. Люди защищают не процесс а привычку. Сопротивление идет оттуда.

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

Сохранил.

Взял на заметку спасибо.

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

Надеюсь, это будет полезно.

Я столкнулся с тем же два года назад. Код без документации не принадлежит вам, даже если он у вас есть.

После сдачи проекта система продолжает жить; обслуживание — отдельная статья расходов. Интересно, есть ли те, кто делает иначе.

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

Пишите, если есть вопросы, отвечу по мере возможности.

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

Это мое мнение, не утверждаю, что оно единственно верное.

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

Если в договоре не прописано право собственности на код, при уходе у вас нет переговорной позиции. Оставлю как заметку, пригодится.

Расскажу, как это делается на практике. После сдачи проекта система продолжает жить; обслуживание — отдельная статья расходов.

Исправьте, если я ошибаюсь.