Прихована ціна неправильного вибору архітектури

БІЗНЕС, НЕ ТЕХНОЛОГІЇ

Чому вибір платформи починається не з технологій, а з розуміння бізнесу

Кожні кілька років змінюється джерело.

Але помилка залишається тією самою.

Десять років тому власники бізнесу говорили нам:

«Розробник порадив Laravel.»

Пізніше це звучало трохи інакше:

«У знайомого інтернет-магазин працює на Magento. Мабуть, і нам варто перейти на Magento.»

Сьогодні ми все частіше чуємо іншу фразу.

«AI рекомендував Laravel.»

Джерело змінилося.

А ось припущення лишилося незмінним.

Як і ціна помилки.

Одразу хочу прояснити одну річ.

Ця стаття не про те, що 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.

Індивідуальна розробка чи готова 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. Він може проаналізувати все це за кілька хвилин, хіба ні?»

Чесно?

Ми б теж цього хотіли.

І штучний інтелект справді дуже змінив правила гри.

Сьогодні він здатний знайти помилки в коді.

Допомогти з аудитом.

Пояснити складну архітектуру.

Пришвидшити аналіз 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.»	Чому саме Laravel? Що перестало влаштовувати у поточній системі?
«Хочемо перейти на Magento.»	Скільки у вас товарів? Які інтеграції? Чому саме Magento, а не Shopify, OpenCart чи Laravel?
«Нам потрібен Shopify.»	Через швидкість запуску? Простішу підтримку? Міжнародні продажі? Чи тому, що хтось порадив?
«OpenCart нам більше не підходить.»	А що саме не підходить: CMS, UX, швидкодія, SEO чи бізнес-процеси?
«AI рекомендував Symfony.»	Яке саме запитання ви поставили AI? Який контекст він отримав?
«Потрібно повністю переробити сайт.»	Ви впевнені, що проблему не вирішить редизайн або покращення UX без зміни архітектури?
«Скільки коштує сайт на Laravel?»	Що саме має входити в цю оцінку: ERP, CRM, AI, склади, B2B, SEO, міграція даних, особистий кабінет, інтеграції?
«Я вже знаю, що мені потрібно.» 😉	Чудово. Тоді давайте перевіримо, чи справді це так.

Якщо після кожного нашого запитання у вас виникає ще два нових, це абсолютно нормально.

Саме так і виглядає етап Discovery.

Досвідчені консультанти відрізняються не тим, що знають усі відповіді.

А тим, що ставлять запитання, про які більшість компаній навіть не замислюється.

Саме після цього ми переходимо до Architecture Discovery Framework.

Бо лише тоді вибір технології перестає бути здогадкою і починає спиратися на розуміння бізнесу.

НАШ ПІДХІД

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

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

Не з технологій.

Із запитань.

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

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

Мета цього Framework не в тому, щоб підказати, що краще: Laravel чи Symfony, Magento чи Shopify.

Його завдання набагато важливіше.

Допомогти зрозуміти, чи справді технологія є тією проблемою, яку потрібно вирішувати.

На практиці це та сама розмова, яку ми проводимо в рамках Strategic Session, ще до обговорення термінів і бюджету розробки.

ЕТАП 1: БІЗНЕС

Етап 1. Зрозумійте бізнес

Перш ніж говорити про платформи, потрібно зрозуміти сам бізнес.

Запитайте себе:

• Яку проблему ми насправді намагаємося вирішити?

• Чому цей проєкт виник саме зараз?

• Що змінилося?

• Яким має бути результат через рік після запуску?

• Що станеться, якщо ми взагалі нічого не змінюватимемо?

Чому це важливо

Технологія має допомагати бізнесу досягати цілей.

Вона не повинна ставати ціллю сама по собі.

Саме на це запитання зазвичай відповідає Usability Audit, ще до того, як написано хоч один рядок нового коду.

ЕТАП 2: КЛІЄНТИ

Етап 2. Зрозумійте своїх клієнтів

Архітектура повинна підтримувати поведінку клієнтів, а не наші припущення про неї.

Запитайте себе:

• Хто наш основний клієнт?

• Це B2B, B2C чи обидві моделі?

• Хто приймає рішення про покупку?

• Це емоційна чи раціональна покупка?

• Купують для себе, для компанії чи як подарунок?

• Що важливіше для клієнта: ціна, довіра, швидкість чи сервіс?

• З яких пристроїв найчастіше здійснюються покупки?

• На яких ринках ми працюємо сьогодні? На які плануємо виходити завтра?

Чому це важливо

Та сама технологія може чудово працювати для одного бізнесу й зовсім не підходити для іншого.

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

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

Етап 3. Оцініть поточну систему

Не поспішайте вважати, що проблема саме в платформі.

Спробуйте чесно відповісти:

• Що сьогодні працює добре?

• Що справді дратує користувачів?

• Чи є документація?

• Чому в минулому були прийняті саме такі архітектурні рішення?

• Проблема технічна, UX, SEO чи взагалі стосується бізнес-процесів?

Чому це важливо

Іноді найкращою архітектурою виявляється та, яка вже існує.

Питання, хто підтримуватиме систему далі, теж варто продумати заздалегідь, і тут часто допомагає 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.

Набагато частіше проблеми виникають значно раніше.

У той момент, коли бізнес перестає досліджувати й починає шукати готові відповіді.

AI змінив дуже багато.

Отримати відповідь стало швидше.

Але зрозуміти, яке саме запитання потрібно поставити, стало ще важливіше.

Саме тому хороша архітектура починається не з вибору технології.

Вона починається з дослідження.

З готовності поставити під сумнів власні припущення.

І з бажання спочатку зрозуміти проблему…

…а вже потім шукати її рішення.

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

І майже завжди вони починаються з неправильного запитання.