Типовий виробничий SMB на 30–100 чоловік рано чи пізно впирається в стелю: власна ERP для виробництва замість Bitrix24 стає не примхою, а операційною необхідністю. Каталог із десятками опцій не вміщується в стандартні поля CRM. Розрахунки розходяться між менеджерами, бо кожен тримає свою версію Excel. Інтеграція з виробничим процесом існує лише на папері. Кожна нова автоматизація через SaaS-API коштує дорого і займає місяці. Саме в цей момент PreBuild — виробник збірних гаражів і модульних будівель з власним заводом у Дніпрі — вирішив будувати свою систему. У цій статті розберемо, як саме вони це зробили, які рішення виявились правильними і де довелось переробляти.
Контекст клієнта і вихідна ситуація
PreBuild виробляє збірні гаражі та модульні будівлі із сендвіч-панелей. Є власний завод, є відділ монтажу, є менеджери продажів. Клієнти — і приватні особи (переважно), і бізнес: СТО, складські комплекси, гаражні кооперативи.
До початку роботи над власною платформою стек виглядав стандартно для виробничого SMB: – WordPress з контактними формами для генерації заявок – Bitrix24 як CRM для ведення угод – Excel для розрахунків вартості під кожен проєкт – Телефон і месенджери — для решти комунікацій
На перший погляд — цілком робочий набір. На практиці — три системних блоки, які заважали масштабуватись.
Чому Bitrix24 перестав вистачати
Головна проблема PreBuild — комбінаторна складність каталогу. Гараж не є стандартним товаром. Він визначається типом профілю, товщиною і видом облицювання, наявністю воріт (і яких), типом фундаменту, регіоном монтажу (впливає на снігові та вітрові навантаження). Множиш ці параметри між собою — отримуєш сотні варіантів.
У Bitrix24 це не вміщувалось у стандартну структуру «товар із ціною». Інтегратори давали оцінку на кастомізацію — приблизно 80% вартості повної нової системи, при цьому із прив’язкою до платформи назавжди.
Розрахунки в Excel — окреме джерело помилок
Кожен менеджер тримав свою версію розрахункового файлу. Формули оновлювались не синхронно. Коли в матеріалах змінювалась ціна — не всі файли оновлювались одразу. Результат: два менеджери могли назвати клієнту різні цифри за одну й ту саму конфігурацію. Довіра клієнта підривалась, репутація — теж.
Зв’язок із виробництвом — паперовий
Кожне замовлення передавалось у виробництво у вигляді паперового передавального листа. Статус виконання — у голові майстра або у WhatsApp-групі. Менеджер продажів не міг сказати клієнту, коли буде готово, без окремого дзвінка на завод.
Контентна робота — вручну і повільно
Сайт потребував постійного наповнення. Але статті писались вручну — по одній, повільно. За рік — близько 20 публікацій. Цього не вистачало для SEO-трафіку, на який розраховував бізнес.
Сумарно — власник дозрів до рішення будувати власну операційну систему. Питання було: як саме.
Виклик і вибір: build vs buy
Вибір між «купити готове» і «збудувати своє» — один із найважливіших у розвитку будь-якого виробничого бізнесу. Для PreBuild він мав конкретні параметри.
Чому не кастомізувати Bitrix24
Оцінка від інтегратора Bitrix24 показала: щоб отримати потрібну функціональність (кастомний каталог із опціями, автоматичний розрахунок, зв’язок із виробництвом), потрібно написати стільки кастомного коду, що вартість впритул наближалась до нової системи. При цьому залишалась жорстка залежність: оновлення платформи можуть ламати кастомні модулі, а підтримку міг надавати тільки той самий інтегратор.
Чому не Salesforce або Pipedrive
Salesforce — потужна система, але орієнтована на масові B2B-продажі, не на виробничий процес із кастомним каталогом. Pipedrive зручний для менеджерів, але теж не вирішує проблему комбінаторики опцій і зв’язку з виробництвом. Обидва варіанти потребували б такого ж обсягу кастомізації — і ті ж проблеми з залежністю.
Чому не Odoo
Odoo — популярний відкритий ERP, де є і виробничий модуль, і CRM, і каталог. Але для PreBuild він виявився надто широким: складне налаштування, важка локалізація під українські реалії (ДБН, локальні специфікації, мовні версії), і насамперед — BIM-модуля в Odoo немає за замовчуванням, а інженерна частина була ключовою вимогою.
Рішення: повна власна ERP на сучасному стеку
PreBuild разом із командою Directoria обрав шлях повної власної системи. Технічний стек визначали за двома критеріями: сучасний, але не екзотичний (легко знайти розробників) і масштабований (можна додавати модулі без переписування ядра).
Вибір зупинився на: FastAPI + SQLAlchemy 2.0 (async) + PostgreSQL 16 + Redis + React 18 + TypeScript.
Орієнтовний бюджет на старті: пілот першого CRM-модуля — близько 150 тис. ₴, далі — покрокове нарощування по модулях. Повна реалізація всіх підсистем — горизонт 12–18 місяців. На момент публікації цього матеріалу пройдено близько 9 місяців.
Ключова відмінність від «купити готове»: система залишається власністю PreBuild. Немає підписки. Немає залежності від постачальника. Є власний IP, який не перепродаси конкурентам.
Архітектура: три домени і сім контейнерів
Вся платформа поділена на три функціональних домени, кожен із яких виконує окрему роль.
Лідогенерація залишилась на WordPress. Це правильне рішення: WordPress чудово справляється з SEO і контентом, а перебудовувати те, що й так добре працює, немає сенсу. Сайт prebuild.com.ua залишився публічним обличчям бізнесу.
Операційний бекенд — це власна ERP-платформа, внутрішня система, де мешкають усі бізнес-процеси: від реєстрації ліда до формування виробничої специфікації.
Каналізація — Telegram і IP-телефонія. Telegram виступає основним UI для менеджерів: сповіщення, швидке прийняття рішень, без потреби заходити в адмінку. Asterisk забезпечує IP-телефонію і готується до інтеграції з CRM для call-трекінгу.
Розгортання: 7 Docker-контейнерів
Увесь стек живе на одному VPS і розгорнутий через Docker Compose. Сім контейнерів:
- PostgreSQL 16 — основна база даних
- Redis 7 — кеш і черги задач
- FastAPI — бекенд-API
- React/Vite — фронтенд-інтерфейс
- aiogram Telegram-бот — нотифікації і взаємодія з менеджерами
- Nginx — reverse-proxy, маршрутизація трафіку
- Asterisk — IP-телефонія
Docker Compose дозволив розгортати, оновлювати і відкочувати сервіси незалежно. Це виявилось однією з найбільш вдалих архітектурних рішень — деплой нової версії бекенду не чіпає телефонію, а перезапуск бота не зачіпає базу.
ERP: 11 модулів і реальні розміри
Ядро платформи — 11 модулів. Не всі однаково зрілі: є ті, що вже в продакшні, і є каркаси, які чекають свого часу.
CRM з 9-стадійним пайплайном
Стандартний пайплайн у більшості CRM — 4–5 стадій. Для виробничого бізнесу цього не вистачає. У PreBuild виробничий цикл проходить через: новий запит → кваліфікація → прорахунок → специфікація → виробництво → доставка → монтаж → підписання акту → закрита угода. Кожна стадія — окремий статус із власними полями та тригерами сповіщень.
Обсяг CRM-модуля: 2273 рядки Python. Це не «привіт, я CRM», це реальна бізнес-логіка.
Catalog з комбінаторикою опцій
Модуль каталогу вирішує головний біль PreBuild — він знає про всі комбінації параметрів і обраховує ціну правильно для кожної. Тип профілю, вид облицювання, конфігурація воріт, тип фундаменту, регіон — все враховується автоматично. Менеджер не вигадує ціну з голови, система дає точну цифру.
Кабінет клієнта
Окрема публічна частина, де замовник самостійно бачить статус свого замовлення: чи готові матеріали, чи передані у виробництво, коли планується доставка. Це знімає значну частину «де мій гараж?» дзвінків — клієнт має відповідь, не витрачаючи час менеджера.
Авторизація з 5 ролями
Система розмежування доступу: owner, manager, director, warehouse, viewer. Не «всі бачать все», а реальні дозволи на дії. Комірник бачить складські операції, менеджер — свої угоди і загальний pipeline, директор — аналітику і доступ до всього.
Що свідомо відкладено
Модулі HR, Finance, Production і Reports у системі присутні як каркаси, але не наповнені повною логікою. Рішення — правильне: спочатку стабілізувати CRM + BIM + Catalog, які є критичними для операційки, і тільки потім нарощувати менш пріоритетні блоки.
BIM Engine: інженерний двигун у серці системи
BIM-двигун — найнетиповіша і найунікальніша частина платформи PreBuild. Це не «ще один модуль ERP». Це окремий інженерний програмний продукт, вбудований у систему.
Що таке BIM у контексті виробника
BIM (Building Information Modeling) у класичному розумінні — це цифрова модель будівлі з усіма параметрами: геометрія, матеріали, навантаження, документація. У PreBuild BIM — це не просто 3D-картинка для маркетингу. Це розрахунковий двигун, який моделює гараж як інженерний об’єкт: перевіряє навантаження за ДБН, формує специфікацію матеріалів, генерує технічну документацію.
Навіщо це виробнику збірних будівель
Без BIM кожен прорахунок проходить через інженера вручну. Клієнт дзвонить, називає розміри — інженер сідає, рахує снігові і вітрові навантаження для конкретного регіону за ДБН, підбирає профілі, перевіряє несучу здатність, формує BOM (специфікацію матеріалів). Це 1–3 дні роботи кваліфікованого спеціаліста на кожне звернення.
PreBuild отримував 10–14 запитів на тиждень. Уявіть: кожен із них — 1–3 дні інженера. Або клієнт чекає і часто іде до конкурента, або тримаєш штат інженерів, де більшість часу рахують типові конфігурації.
Як BIM-двигун працює технічно
Увесь двигун — близько 1900 рядків Python, розбитих на спеціалізовані модулі:
- Каркас формується на основі введених розмірів: розраховуються ЛСТК-профілі або профтруба залежно від конфігурації
- Перевірка навантажень враховує регіон (снігові зони, вітрові райони за картами ДБН), тип конструкції і призначення будівлі
- Bill of Materials автоматично формує повний перелік матеріалів з кількостями
- DXF-креслення генеруються у форматі, придатному для передачі на верстати
- Проєктна документація формується автоматично — готовий комплект для замовника
Весь ланцюжок від введення параметрів до готового пакету документів займає 30 секунд.
Що це дало PreBuild в операційних цифрах
Час від запиту до прорахунку скоротився з 1–3 днів до 30 секунд для автоматичної частини плюс 10 хвилин для інженерної валідації. Інженер тепер не рахує — він перевіряє результат, який уже готовий. Це зовсім інша роль і зовсім інша завантаженість.
Калькулятор на сайті став реальним інструментом. Не «залишіть заявку, ми порахуємо», а справжнє онлайн-обчислення за параметрами клієнта. Подивитись, як це виглядає в дії, можна на калькуляторі гаража PreBuild.
Відсоток помилок у специфікаціях знизився суттєво. Коли розрахунок детермінований — ті самі вхідні параметри завжди дають той самий результат. Людський фактор вилучається з розрахункового ланцюжка.
Що BIM-двигун не робить
Варто зазначити чесно: BIM-двигун PreBuild — не AI і не «розумна система». Він детермінований: є формули, є ДБН, є логіка вибору параметрів. Вхід → обчислення → вихід. Він не пропонує альтернативних конструктивних рішень, не оптимізує вартість автоматично, не «розуміє» нестандартні запити.
AI в платформі допомагає в інтерфейсі та комунікаціях — але не в BIM-розрахунках. Розмежування важливе: не треба очікувати від інженерного двигуна того, чого він не обіцяє.
Інтеграція WordPress ↔ ERP ↔ Telegram ↔ Asterisk
Окремо варто розібрати, як усі ці системи з’єднані між собою — бо саме склейка часто є найслабшою ланкою в подібних проєктах.
Від форми на сайті до ліда в CRM
Коли відвідувач сайту заповнює форму запиту, відбувається такий ланцюжок:
- Форма на сайті (shortcode на WordPress-сторінці) приймає дані через AJAX
- PHP-обробник надсилає запит одночасно в Telegram-бота і в ERP-webhook
- ERP автоматично створює Lead, Contact і потенційну угоду
- Угода потрапляє в pipeline зі стадією «Новий»
- Менеджер отримує Telegram-сповіщення з деталями запиту і посиланням на угоду в CRM
Час від надходження форми до того, як менеджер бачить сповіщення — секунди. Раніше заявки могли “лежати” кілька днів у загальному поштовому ящику. Зараз час від форми до першого контакту — 1 година в робочий час.
Жодна заявка більше не губиться.
Telegram як операційний інтерфейс
Окрема Telegram-інтеграція заслуговує на увагу. Більшість систем вимагають: відкрий браузер, увійди в адмінку, знайди запис, онови статус. Менеджери продажів не хочуть і не будуть цього робити постійно — особливо коли вони в роз’їздах.
У PreBuild Telegram-бот став основним робочим інтерфейсом для оперативних дій. Сповіщення про нові заявки, зміни статусів, нагадування — все приходить у Telegram. Менеджер може відповісти прямо там.
IP-телефонія: готова, але ще не інтегрована повністю
Asterisk розгорнутий у Docker поряд із рештою стеку. SIP-транк до українського провайдера активний, менеджер уже приймає дзвінки через софтфон. Але call-трекінг — прив’язка дзвінка до конкретної угоди в CRM — поки в дорожній карті. Це наступний пункт після стабілізації основних модулів.
Синхронізація цін із сайтом
Ціни на WooCommerce-сторінках частково синхронізуються з ERP через WooCommerce API. Повна автоматична синхронізація — теж у дорожній карті. Поки що зміна цін у ERP частково вимагає ручного підтвердження на сайті.
llms.txt і LLM-готовність: нестандартний хід
Є одна деталь у платформі PreBuild, яка заслуговує окремої уваги — і яку майже ніхто з українських SMB не робить.
На сайті prebuild.com.ua розгорнуто повноцінну підтримку формату llms.txt — спеціального файлу, який описує структуру і зміст сайту для AI-агентів: ChatGPT, Claude, Perplexity, Google AI Overviews.
Навіщо це потрібно
Коли користувач запитує в ChatGPT або Perplexity «гараж із сендвіч-панелей в Україні», система відповідає, цитуючи джерела. Яке джерело буде процитовано — залежить від того, наскільки добре AI-агент «розуміє» сайт. llms.txt — це машиночитаний контекстний файл, який допомагає AI-агентам правильно індексувати зміст.
PreBuild — один із небагатьох українських SMB, які вже зараз готуються до цього каналу трафіку.
Як реалізовано технічно
WordPress mu-plugin pb-llms.php автоматично анонсує три файли у <head> кожної сторінки: llms.txt (базовий), llms-ru.txt (для російськомовного контенту) і llms-full.txt (повний, 485 KB). Файли генеруються Python-скриптом із WordPress REST API і оновлюються через cron-завдання.
Результат — сайт уже цитується у вибірках Perplexity і ChatGPT при релевантних запитах.
Результати в цифрах
Наведемо зведену таблицю того, що змінилось після запуску платформи.
| Метрика | До | Після |
|---|---|---|
| Час від запиту до контакту менеджера | кілька днів | 1 година в робочий час |
| Час інженера на прорахунок замовлення | 1–3 дні | 30 секунд (авто) + 10 хвилин (валідація) |
| Прорахунок самим клієнтом онлайн | неможливий | 2 хвилини через калькулятор |
| Загублені заявки | непомітні (губились у email) | 0 |
| Статей у блозі за рік | ~20 | 200+ |
| Присутність у відповідях AI-систем | 0 | цитування в Perplexity і ChatGPT |
| Кількість менеджерів для тих самих обсягів | 3 | 1–2 (інші — у виробництві та монтажі) |
Цифри показують не «у нас зросли продажі на X%». Вони показують операційну ефективність: менше людей виконує той самий обсяг роботи, клієнти отримують відповідь швидше, заявки не губляться.
Конвертація в угоди залежить від багатьох факторів поза системою — але система забезпечує, що жоден потенційний клієнт не зникає і кожен отримує відповідь вчасно.
Уроки і що ми зробили б інакше
Чесний розбір — важливіший за маркетинговий огляд. Ось що реально спрацювало і що варто було зробити по-іншому.
Що спрацювало добре
Модульна архітектура виявилась ключовим рішенням. Замість «все або нічого» — поступовий запуск: спочатку CRM, потім BIM, потім Catalog. Кожен модуль давав цінність одразу після запуску, не очікуючи решти.
FastAPI + Postgres + React — вибір типового, але якісного стеку. Не модного, не екзотичного. Коли потрібно підключити нового розробника або знайти допомогу з конкретною задачею — звична технологія заощаджує час і гроші.
Docker Compose з нуля спростив деплой у рази. Немає ручного розгортання, немає «а на якому сервері що стоїть». Один docker-compose up — і вся система піднімається.
BIM-двигун як окремий компонент — важливе архітектурне рішення. Він не переплетений із CRM-логікою, а взаємодіє через чіткі інтерфейси. Це дозволило розробляти і тестувати його незалежно.
Що варто було зробити інакше
Недооцінили складність каталогу з опціями. Комбінаторика виявилась значно складнішою, ніж здавалось на старті. Профіль × облицювання × ворота × фундамент × регіон — це не просто таблиця. Це складна логіка ціноутворення з виключеннями і залежностями. На планування цього модуля треба було закласти більше часу від початку.
Polylang на WordPress місцями не вистачає. Сайт двомовний (UA/RU), і деякі сценарії мультимовності виявились складнішими, ніж передбачалось. Треба було продумати i18n у ERP із самого початку — зараз це ускладнює деякі інтеграції.
Слабке покриття автотестами в перший місяць. Коли поспішають запустити перший модуль, тести часто відкладають. У PreBuild це дало про себе знати пізніше: коли почали додавати BIM поверх CRM, довелось писати тести заднім числом — і тоді ж знаходити неочевидні баги.
Хибне очікування, яке не справдилось
Очікували, що AI напише «майже весь UI». На практиці — ні. UI пишуть люди. AI допомагає з реалізацією окремих функцій, генерує шаблони, прискорює рутину — але не замінює frontend-розробника, який розуміє UX і бізнес-логіку. Хто закладає в план «AI все напише» — той помиляється у вартості та часових рамках.
Кому підходить власна ERP: коли build перемагає buy
Кейс PreBuild — не аргумент «кожен повинен будувати своє». Це приклад для конкретного типу бізнесу. Розберемо, кому підходить такий підхід.
Кому варто серйозно розглядати
Виробничі SMB з кастомним каталогом. Якщо ваш продукт неможливо описати стандартним набором полів SaaS-CRM — це сигнал. Виробники меблів на замовлення, виробники вікон і дверей із кастомними розмірами, виробники металоконструкцій — всі вони стикаються з тією самою проблемою, що й PreBuild.
Сервісні компанії з інженерною складовою. Будівельні компанії, інженерні підрядники, компанії зі спецтехнікою — там, де «продати» = «спочатку порахувати технічно», стандартні CRM не вистачає.
Компанії, які виходять на новий ринок або хочуть тримати інфраструктуру у власності. Особливо актуально для тих, хто думає про масштабування: своя система — це актив, підписка — це витрати.
Бізнеси, де SaaS-підписки стали обмеженням, не інструментом. Якщо ви платите за 3–4 SaaS-сервіси, вони не інтегровані між собою, і щомісяця виникають «а це не синхронізується» — це сигнал переглянути підхід.
Кому ще зарано або не підходить
Менше 20 чоловік у компанії. Bitrix24, Pipedrive або навіть Google Таблиці ще цілком справляються. Власна ERP — це overhead, який малий бізнес не відіграє.
Бізнес із типовим товарообігом без кастомної специфіки. Якщо продаєте стандартні товари зі стандартними цінами — CRM, яка коштує у 10 разів менше, зробить те саме.
Стартапи у пошуку product-market fit. Спочатку треба підтвердити, що продукт взагалі потрібен ринку. Власна ERP на цьому етапі — відволікання ресурсів від головного.
Орієнтовний бюджет для старту
Щоб план був конкретним:
- Discovery + аудит процесів — 15 000 ₴ (5 робочих днів), виходить ТЗ на систему
- Пілот першого модуля (наприклад, CRM + базовий каталог) — 200–400 тис. ₴, 6–10 тижнів
- Розгортання наступних модулів — підписка на розробку 80–150 тис. ₴/міс на 6–12 місяців
- BIM-двигун (якщо є інженерна частина) — окремий блок, 300–500 тис. ₴
Загальна вартість повної платформи PreBuild-рівня — від 1,5 млн ₴ за 12–18 місяців. Це звучить значно — але порівняйте з альтернативою: кілька розробників Bitrix на рік + підписки + втрачені угоди через невчасні відповіді.
Часті питання
Чи обов’язково переходити з Bitrix24 повністю, чи можна паралельно?
Паралельна робота двох систем зазвичай гірша, ніж будь-яка з них окремо. Дані дублюються, менеджери плутаються, де актуальна інформація. PreBuild перейшов на власну систему повністю — без збереження Bitrix у паралелі. Якщо рішення прийнято будувати, варто планувати повну міграцію, не «на всякий випадок залишити старе».
Скільки часу займає впровадження?
У PreBuild перший модуль (CRM) запустили через 6–8 тижнів після початку розробки. BIM-двигун додали ще через 3–4 місяці. Повна платформа в поточному вигляді — близько 9 місяців з моменту старту. Але бізнес отримував цінність поступово, не чекаючи фіналу.
Чи потрібен власний DevOps-спеціаліст для підтримки?
Для підтримки Docker Compose на VPS — ні, не потрібен виділений DevOps. Базові операції (оновлення, перезапуск, бекапи) виконує розробник або навіть технічно грамотний менеджер за інструкцією. Складніші речі — масштабування, міграції — разовий залучений спеціаліст.
Що відбувається, якщо щось ламається на серверній стороні?
Docker Compose дозволяє перезапустити конкретний контейнер, не зачіпаючи решту. База даних ізольована, бекапи автоматизовані. Крах фронтенду не вбиває бекенд. Ці речі закладались в архітектуру з самого початку.
Чи підходить такий стек для компаній з EU-клієнтами або релокованого бізнесу?
FastAPI + Postgres + React — стандартний стек, прийнятий у всіх юрисдикціях. GDPR-вимоги вирішуються на рівні архітектури даних, не стеку. Компанії з EU-клієнтами можуть розгортати систему на EU-хостингу без змін у коді.
Де можна побачити, як платформа PreBuild виглядає з боку клієнта?
Публічна частина — сайт prebuild.com.ua. Там видно і форму заявки, і онлайн-калькулятор, і блог із двомовним контентом. Внутрішня ERP-частина для клієнтів недоступна — це приватна операційна система.
Яка різниця між цим кейсом і впровадженням типового модуля автоматизації?
Типовий модуль автоматизації — це надбудова над існуючим SaaS (наприклад, Zapier-інтеграції або чат-бот поверх Bitrix). Кейс PreBuild — це заміна SaaS власною системою. Різний рівень складності, різний бюджет, різна цінність. Перший варіант підходить для точкових задач, другий — коли ціла операційна архітектура більше не відповідає потребам бізнесу.
Висновок
Кейс PreBuild демонструє одну важливу річ: рішення «будувати своє» — не про амбіції, а про конкретні операційні обмеження, які SaaS-підписка не може вирішити. Коли каталог не вміщується в стандартні поля, розрахунки розходяться між менеджерами, а інтеграція з виробництвом існує тільки на папері — настає момент, коли build перемагає buy.
Якщо ваш бізнес упирається у схожі обмеження і ви думаєте про власну операційну систему — почніть з аудиту. П’ять днів, щоб зрозуміти, де система потрібна, а де вистачить доналаштування існуючого. Замовте безкоштовний AI-аудит — і отримаєте чіткий план замість абстрактних розмов про «цифрову трансформацію».
