Скрытая цена неправильного выбора архитектуры

БИЗНЕС, НЕ ТЕХНОЛОГИИ

Почему выбор платформы начинается не с технологий, а с понимания бизнеса

Каждые несколько лет меняется источник.

Но ошибка остается прежней.

Десять лет назад владельцы бизнеса говорили нам:

«Разработчик посоветовал Laravel.»

Спустя несколько лет это звучало уже иначе:

«У знакомого интернет-магазин работает на Magento. Наверное, и нам стоит выбрать Magento.»

Сегодня мы слышим новую версию.

«ChatGPT (или AI) порекомендовал Laravel.»

Источник изменился.

Предположение осталось тем же.

Как и цена ошибки.

Сразу хочу прояснить одну вещь.

Эта статья не против AI.

Совсем наоборот.

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

AI стал одним из самых полезных инструментов в нашей работе.

Проблема не в AI.

Она появилась задолго до него.

Люди всегда стремились получить ответ раньше, чем успевали по-настоящему понять вопрос.

AI лишь многократно ускорил этот процесс.

Очень многие разговоры начинаются практически одинаково.

«У нас интернет-магазин на десять тысяч товаров и около ста тысяч посетителей в месяц. Хотим перейти на Laravel. Сколько это будет стоить?»

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

На самом деле, почти нет.

Потому что эти цифры практически ничего не говорят о самом проекте.

Не потому, что они неправильные.

А потому, что они отвечают на вопрос, которого мы еще даже не задали.

Представьте, что вы звоните архитектору и спрашиваете:

«Сколько будет стоить построить дом площадью 300 квадратных метров?»

Это совершенно нормальный вопрос.

Но ответить на него профессионально невозможно.

Архитектор не знает, где находится участок.

Какой у него рельеф.

Какой фундамент потребуется.

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

Будет ли этот дом продаваться через пять лет.

Или его планируют передать детям.

Площадь дома имеет значение.

Но сама по себе она почти ничего не определяет.

С архитектурой цифровых продуктов всё точно так же.

Именно поэтому на первой встрече мы почти никогда не начинаем разговор с Laravel, Symfony, Magento, Shopify, WordPress, OpenCart или любой другой технологии.

Не потому, что технологии не важны.

Они важны.

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

Можно случайно принять правильное решение.

Но оно всё равно останется случайностью.

Именно здесь чаще всего несправедливо обвиняют AI.

Мы слышим это постоянно.

«AI посоветовал Laravel.»

Или Symfony.

Или Magento.

Или Shopify.

Или WordPress.

Наш ответ почти всегда одинаковый.

Скорее всего, AI не ошибся.

Вы просто задали ему неправильный вопрос.

А это совершенно разные вещи.

Посмотрите еще раз на исходный запрос.

«У меня интернет-магазин на 10 000 товаров и 100 000 посетителей в месяц. Какую платформу выбрать?»

Внутри одной этой фразы уже скрыто несколько предположений.

Что проблема именно в текущей платформе.

Что смена платформы будет правильным решением.

Что именно архитектура должна стать следующим крупным вложением бизнеса.

Но ведь ни одно из этих утверждений еще не было проверено.

Они просто были приняты как факт.

AI их не оспаривает.

Он отвечает на поставленный вопрос.

Именно так, как и должен.

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

Очень часто можно услышать:

«AI дал плохой совет.»

В большинстве случаев это не так.

Он дал вполне разумный ответ…

…на плохо сформулированный вопрос.

И это далеко не одно и то же.

Мы разбирали похожую ситуацию в статье Four AIs Agreed. We Still Hadn't Verified Anything: согласие сразу нескольких моделей ещё не значит, что кто-то что-то проверил.

Мы наблюдаем этот сценарий снова и снова.

Раньше люди полностью доверяли мнению разработчика.

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

Сегодня доверяют AI.

Источник меняется.

Человеческая модель поведения, нет.

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

Именно в этот момент и начинаются самые дорогие ошибки.

Не тогда, когда компания выбирает Laravel вместо Symfony.

Не тогда, когда переходит с OpenCart на Magento.

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

Самая дорогая ошибка происходит гораздо раньше.

В тот момент, когда бизнес незаметно для самого себя принимает решение, что проблема заключается в технологии…

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

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

«Хорошо, тогда что бы сделали вы?»

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

Laravel против Symfony.

Magento против Shopify.

WordPress против OpenCart.

Custom Development против готовой CMS.

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

На самом деле…

Он должен был начаться намного раньше.

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

Предыдущий проект был построен на OpenCart.

Платформа уже не казалась современной.

На рынке всё чаще говорили о Laravel.

Появлялось всё больше статей, видео, рекомендаций.

Казалось, ответ очевиден.

Пришло время переходить.

Мы задали ему всего один вопрос.

Почему?

Не почему Laravel.

Почему вообще нужно менять платформу?

Ответ оказался вполне логичным.

Текущая CMS казалась устаревшей.

Laravel выглядел современнее.

К тому же хотелось оставить запас на будущее.

«Чтобы потом не пришлось всё переделывать.»

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

И, честно говоря, он звучит убедительно.

До тех пор, пока не начинаешь считать.

Мы обсудили не только стоимость разработки.

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

Потому что любой бюджет ограничен.

Каждый доллар, вложенный в разработку, уже нельзя вложить в SEO.

В рекламу.

В контент.

В исследования.

В улучшение пользовательского опыта.

В автоматизацию отдела продаж.

Всё это тоже инвестиции.

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

Клиент внимательно выслушал все аргументы.

После чего сказал:

«Я понимаю. Но всё равно хочу Laravel.»

Это был его бизнес.

Его деньги.

Его решение.

Мы разработали проект именно так, как он хотел.

И проект действительно получился хорошим.

Сайт работал быстро.

Архитектура была чистой.

Платформа легко масштабировалась.

Laravel полностью оправдал ожидания.

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

И тогда клиент неожиданно сказал фразу, которую мы потом слышали ещё не раз.

«Наверное, вы тогда были правы.»

Не потому, что Laravel оказался плохим выбором.

Совсем нет.

Он оказался именно тем, что ожидалось.

Но позже стало очевидно другое.

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

Это дорогой урок, и похожие ситуации мы описали в статье The Most Expensive Mistake Business Owners Make Before Hiring a Digital Agency.

В SEO.

В привлечение клиентов.

В повышение доверия.

В контент.

В аналитику.

Всё то, что напрямую влияет на продажи.

Laravel решил задачу.

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

Именно в этом разница между правильным решением и правильным приоритетом.

Поэтому мы почти никогда не спрашиваем клиента:

«Какую платформу вы хотите?»

Нам гораздо интереснее другой вопрос.

«Куда сегодня принесёт максимальную отдачу следующий вложенный доллар?»

Потому что это уже разговор не о разработке.

Это разговор о бизнесе.

Иногда ответом действительно становится Laravel.

Иногда Symfony.

Иногда Magento.

А иногда…

редизайн существующего сайта.

И, честно говоря, именно этот вариант многим кажется самым неожиданным.

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

«Мы считаем, что новый сайт вам пока не нужен.»

Особенно если разработка нового сайта стоит значительно дороже.

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

Потому что наша задача не в том, чтобы продать разработку.

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

Но бывают и противоположные ситуации.

Клиент приходит с полной уверенностью, что существующий сайт пора отправить на свалку истории.

Новая платформа.

Новая архитектура.

Полный перезапуск.

На первый взгляд всё выглядит вполне логично.

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

Что именно не работает?

Где бизнес теряет деньги?

Что говорят пользователи?

На каком этапе они уходят?

Что мешает продавать?

Что ограничивает рост?

И самое интересное…

Ответы очень редко начинаются со слов:

«Проблема в нашей CMS.»

Гораздо чаще выясняется, что причина совсем в другом.

Пользователи не могут быстро найти нужный товар.

Навигация перестала соответствовать ассортименту.

Поиск работает хуже, чем ожидают клиенты.

Оформление заказа слишком длинное.

Дизайн больше не вызывает доверия.

Мобильная версия неудобна.

Страницы товаров не помогают принять решение о покупке.

Архитектура здесь может быть вообще ни при чем.

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

Иногда достаточно было переработать пользовательский опыт.

Иногда обновить интерфейс.

Иногда пересмотреть структуру каталога.

Иногда провести нормальное исследование поведения пользователей.

И неожиданно оказывалось, что платформа всё ещё прекрасно справляется со своей задачей.

Наверное, одна из самых сложных вещей в нашей работе, честно сказать клиенту:

«Мы не уверены, что вам сейчас нужна новая разработка.»

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

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

Не потому, что так проще.

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

Просто это честнее по отношению к клиенту.

Есть ещё одна проблема, о которой почти никогда не говорят.

Технический долг.

Но не тот, который обычно имеют в виду разработчики.

Самым дорогим оказывается не устаревший код.

Самым дорогим оказывается забытая логика принятия решений.

Мы подробно разбирали это в статье Most Companies Don't Own Their Website. They Own a Collection of Dependencies, и в счёте за разработку это почти никогда не отражается.

За свою жизнь проект редко остаётся в руках одной команды.

Приходит новый разработчик.

Потом агентство.

Потом фрилансер.

Потом ещё одна команда.

Каждый что-то улучшает.

Что-то переписывает.

Добавляет новую интеграцию.

Меняет поиск.

Переделывает оформление заказа.

Исправляет работу фильтров.

Удаляет старые функции.

Добавляет новые.

Сам по себе этот процесс абсолютно нормален.

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

Почему?

Почему этот раздел находится именно здесь?

Почему поиск работает именно так?

Почему была выбрана именно эта логика оформления заказа?

Почему эту интеграцию написали с нуля, хотя существовал готовый модуль?

Почему изменили структуру каталога?

Почему кнопка переехала именно сюда?

И самое неприятное начинается тогда, когда никто уже не может ответить.

Не владелец бизнеса.

Не нынешняя команда.

Не предыдущий подрядчик.

Потому что люди сменились.

Контекст исчез.

Документацию никто не вел.

А код помнит всё.

Вот только объяснить причины он уже не способен.

Именно в этот момент всё чаще появляется ещё одна фраза.

«Но ведь сейчас есть AI. Он же может всё это проанализировать за несколько минут?»

Честно?

Мы бы тоже хотели.

И AI действительно изменил правила игры.

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

Но есть одна вещь, которой он пока не умеет.

Он не знает, почему бизнес когда-то принял то или иное решение.

А именно это «почему» очень часто оказывается важнее самого кода.

Именно поэтому анализ существующей системы редко бывает быстрым.

AI может объяснить, что делает код.

Но далеко не всегда способен объяснить, зачем он появился.

А без понимания этого вопроса любое архитектурное решение остаётся лишь предположением.

Мы всё чаще замечаем одну интересную закономерность.

За последние несколько лет скорость принятия неправильных решений выросла.

Не потому, что люди стали менее компетентными.

Наоборот.

Информации стало больше, чем когда-либо прежде.

Статей.

Видео.

Подкастов.

Обзоров.

AI.

Любой владелец бизнеса может за один вечер узнать о Laravel, Symfony, Magento, Shopify, WordPress, OpenCart или любой другой платформе больше, чем было возможно десять лет назад.

И это замечательно.

До определенного момента.

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

Раньше человек говорил:

«Мне так посоветовал знакомый разработчик.»

Сегодня он говорит:

«Я несколько часов общался с AI, и он тоже рекомендует Laravel.»

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

На самом деле, почти никакой.

И тогда, и сейчас человек пытается найти ответ…

…ещё не до конца поняв собственный вопрос.

Мы даже заметили ещё одну интересную особенность.

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

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

Хотя логика должна работать наоборот.

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

Мы писали об этом в статье The Cost of AI Isn't Generation. It's Verification: непроверенное предположение обходится дорого независимо от того, кто его сделал, человек или модель.

Но даже самая сильная модель не способна компенсировать плохо поставленный вопрос.

Представьте, что вы спросили AI:

«У меня интернет-магазин на 10 000 товаров. Что лучше выбрать: Laravel или Magento?»

Вы получите вполне разумный ответ.

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

Потому что AI не знает:

сколько у вас складов;

работаете ли вы с B2B;

есть ли персональные цены;

нужна ли интеграция с ERP;

планируете ли выход на новые рынки;

есть ли собственное производство;

кто принимает решение о покупке;

что именно не устраивает в текущей системе;

и самое главное…

почему вы вообще решили, что проблема заключается в платформе.

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

Не потому, что технологии не важны.

Потому что в этот момент говорить о них ещё слишком рано.

Сначала нужно разобраться в самом бизнесе.

Понять, как он работает сегодня.

Какие решения привели его в текущую точку.

Что действительно ограничивает рост.

И только после этого обсуждать Laravel, Symfony, Magento, Shopify, WordPress или любую другую платформу.

Не наоборот.

За годы работы этот процесс постепенно превратился в нашу внутреннюю систему принятия решений.

Мы не создавали её за один день.

Она появилась благодаря проектам, в которых мы ошибались.

Благодаря проектам, в которых были правы.

Благодаря разговорам с владельцами бизнеса.

Благодаря исследованиям.

И благодаря сотням часов, потраченным не на разработку…

…а на понимание того, что именно нужно разрабатывать.

Именно так появилась методология, которую сегодня мы называем…

НАШ ПОДХОД

Architecture Discovery Framework: прежде чем рекомендовать технологию

Неважно, идет ли речь о Laravel, Symfony, Magento, Shopify, WordPress, OpenCart, WooCommerce, Next.js, Django, ModX, Joomla или Wix, обсуждение архитектуры мы всегда начинаем одинаково.

Не с технологий.

С вопросов.

За годы работы мы убедились: самые дорогие ошибки возникают не потому, что компания выбрала «не тот» фреймворк или CMS.

Они появляются гораздо раньше, когда решение о технологии принимается еще до того, как бизнес был по-настоящему понят.

Цель этого Framework не в том, чтобы подсказать, что лучше, Laravel или Symfony, Magento или Shopify.

Его задача гораздо важнее.

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

На практике это тот же самый разговор, который мы проводим в рамках Стратегической сессии, ещё до обсуждения сроков и бюджета разработки.

ЭТАП 1: БИЗНЕС

Этап 1. Понять бизнес

Прежде чем обсуждать платформы, необходимо понять сам бизнес.

Задайте себе несколько вопросов:

• Какую проблему мы пытаемся решить?

• Почему этот проект возник именно сейчас?

• Что изменилось?

• Как будет выглядеть успешный результат через год?

• Что произойдет, если мы ничего не будем менять?

Почему это важно

Технология должна решать задачи бизнеса.

Она не должна становиться целью сама по себе.

Именно на этот вопрос обычно отвечает Usability Audit, ещё до того, как написана хоть одна строка нового кода.

ЭТАП 2: КЛИЕНТ

Этап 2. Понять клиента

Любая архитектура должна поддерживать поведение клиентов, а не строиться на предположениях.

Спросите себя:

• Кто наш основной клиент?

• B2B, B2C или обе модели?

• Кто принимает решение о покупке?

• Покупка эмоциональная или рациональная?

• Для себя покупают или для компании?

• Что важнее: цена или доверие?

• С каких устройств чаще совершаются покупки?

• На каких рынках мы работаем сегодня и будем работать завтра?

Почему это важно

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

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

ЭТАП 3: СИСТЕМА

Этап 3. Оценить существующую систему

Не стоит заранее считать, что проблема именно в текущей платформе.

Попробуйте ответить:

• Что сегодня работает хорошо?

• Что действительно не устраивает пользователей?

• Есть ли документация по проекту?

• Почему были приняты предыдущие архитектурные решения?

• Проблема техническая, связана с UX или с бизнес-процессами?

Почему это важно

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

Вопрос, кто будет поддерживать систему дальше, тоже стоит продумать заранее, и здесь часто на помощь приходит IT Outsourcing & Outstaffing.

ЭТАП 4: ВЕСЬ БИЗНЕС

Этап 4. Посмотреть на бизнес целиком

Сайт редко существует сам по себе.

Обычно он является частью гораздо большей системы.

Поэтому важно понять:

• Какие CRM и ERP используются?

• Есть ли интеграции со складами?

• Какие службы доставки подключены?

• Какие платежные системы используются?

• Есть ли B2B-кабинет?

• Используется ли AI?

• Какие внешние сервисы критически важны для бизнеса?

Почему это важно

Архитектура должна объединять процессы, а не создавать еще один изолированный инструмент.

Именно такое сопоставление мы делаем в рамках Business Digitalization, ещё до того, как порекомендовать хотя бы один новый инструмент.

ЭТАП 5: БУДУЩЕЕ

Этап 5. Подумать о будущем

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

Стоит заранее понять:

• Планируется ли выход на новые рынки?

• Появятся ли новые направления бизнеса?

• Планируется ли международная экспансия?

• Нужны ли новые языковые версии?

• Изменится ли бизнес-модель?

• Какие AI-инструменты могут появиться через год-два?

Почему это важно

Хорошая архитектура растет вместе с компанией.

ЭТАП 6: ВОПРОСЫ К AI

Этап 6. Научиться задавать лучшие вопросы

Прежде чем спрашивать AI…

Сначала задайте вопросы себе.

Вместо:

«У меня интернет-магазин на 10 000 товаров. Стоит ли делать его на Laravel?»

Попробуйте сформулировать вопрос так:

«У нас B2B и B2C-бизнес, несколько складов, интеграция с ERP, персональные цены, планы выхода на новые рынки и существующий OpenCart-проект, который технически работает, но становится все дороже в поддержке. Какие дополнительные данные вам нужны, чтобы понять, стоит ли переходить на Laravel, Symfony, Magento, Shopify или сохранить текущую архитектуру?»

Почему это важно

Чем лучше вопрос, тем ценнее будет ответ.

Не только от AI.

От любого эксперта.

Подробнее о том, где именно AI действительно ускоряет процесс, мы писали в статье How AI Is Changing Product Development in 2026 (But Great Ideas Still Win).

ЭТАП 7: ТЕХНОЛОГИИ

Этап 7. Только теперь можно обсуждать технологии

Только после этого имеет смысл говорить о Laravel.

О Symfony.

О Magento.

О Shopify.

О WordPress.

О OpenCart.

О WooCommerce.

О Next.js.

О Django.

О ModX.

О Joomla.

О Wix.

К этому моменту выбор технологии перестает быть догадкой.

Он становится логичным следствием понимания бизнеса.

ВЫВОД

Правильные вопросы ценнее правильных ответов

Сегодня выбрать технологию стало проще, чем когда-либо.

Laravel.

Symfony.

Magento.

Shopify.

WordPress.

OpenCart.

WooCommerce.

Next.js.

Django.

ModX.

Joomla.

Wix.

Каждая из этих платформ может стать отличным решением.

И каждая может оказаться дорогостоящей ошибкой.

Все зависит не от самой технологии.

А от того, почему она была выбрана.

За годы работы мы убедились в одной простой вещи.

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

Или Magento вместо Shopify.

Или WordPress вместо OpenCart.

Гораздо чаще проблемы возникают значительно раньше.

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

AI изменил многое.

Получить ответ стало быстрее.

Но понять, какой вопрос нужно задать, стало еще важнее.

Именно поэтому никакой искусственный интеллект не способен заменить понимание собственного бизнеса.

Он может ускорить анализ.

Помочь проверить гипотезы.

Подсказать новые идеи.

Но решение по-прежнему принимает человек.

Хорошая архитектура начинается не с выбора платформы.

Она начинается с исследования.

С готовности поставить под сомнение собственные предположения.

С желания сначала понять проблему…

…и только потом искать решение.

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

И почти всегда они начинаются с неправильного вопроса.