Двоє розробників два роки будували ERP для швейних фабрик. За гроші власника, у якого є дві діючі фабрики, готові цим користуватись. Код здебільшого чудовий. Інженерний процес довкола коду майже відсутній, але це все можна виправити. Чого команда виправити не може — це небажання власника наважитись на справжній виробничий запуск.
Двоє розробників два роки будували ERP для швейних фабрик. За гроші власника, у якого є дві діючі фабрики, готові цим користуватись. Він сподівається запустити з цього SaaS-рішення на всю країну, а то й на весь світ. Код здебільшого чудовий і робить свою справу. А от інженерного процесу довкола нього майже не було: ні трекера задач, ні спостережуваності, ні виразного інженерного лідерства.
Але все це можна виправити. Чого полагодити не вийде, і що може завалити все — це небажання власника наважитись на справжній виробничий запуск.
Вступна сцена
Це другий опублікований приклад роботи Engineering Strategy Framework. Попередній — опенсорсний e-commerce фреймворк Solidus: текст і повний аудит. Це — реальний продукт у скруті, тому назва і команда анонімізовані.
Продукт — українська ERP для швейних виробництв на Rails і React, продуктова обіцянка очікувана: працівниця підходить до роздрукованої специфікації в цеху, сканує телефоном її QR-код і отримує список операцій на сьогодні. Відрядна зарплата рахується в міру виконання, а власник бачить цех у реальному часі, замість того, щоб зводити все наприкінці місяця. Kaizen у реальному житті. А я люблю Kaizen, тому й вирішив допомогти.
Команда: двоє недорогих контрактних інженерів (фронтендер на повну зайнятість, бекендер на часткову) і власник, який, скоріше всього, не дуже уявляє, як адмініструвати побудову SaaS-продукту, зате дуже добре знає швейну галузь. Амбітне поєднання, у якому впізнається справжній bootstrapped startup: вони ще не знають, що роблять, але це принаймні дешево та оплачується з власної кишені.
У мене були репозиторій з git history та історія чату в Telegram, бо трекера задач немає… 5 735 повідомлень за 27 місяців. Те, що вони дійшли так далеко без Kanban чи чогось подібного, — справжнє диво!
Два роки розробки — і жодного робочого дня на жодній із двох фабрик власника.
Код — не проблема
Очевидно, перше, що я перевірив, — це код.
Хоча цього ніколи раніше не міряли та не запускали в CI, бекенд має 95% покриття рядків тестами (rspec) на 6 114 прикладах. У фронтенд-SPA є end-to-end браузерні тести: 303 штуки, вони покривають 80% фронтенду і 79% бекенду через API, і для них є робочий CI знайдено. А ще в SPA є написані ADR, PRD, CLAUDE.md та інші сліди сучасного harness engineering. У бекенда всього цього немає, але додати такі речі — це доволі швидко, це не масивна міграція коду.
Процес — теж не проблема (хоча з ним безлад)
Друга моя здогадка — усе, що довкола коду. Ось там справді безлад.
- Немає трекера. Беклогом працює робочий чат. Ця фіча готова? Її протестували? Чого бракує? У кращому разі — шукай повідомлення в чаті, у гіршому — спробуй згадати, що казали в Google Meet.
- Набір тестів, який нічого не охороняє. CI є і вона запускає браузерні тести, але rspec-набір бекенду в CI відсутній. Бекендер проганяє його в себе на машині стейкхолдер. Чи проганяє його фронтендер, коли віддає бекендові фічі, написані з LLM-агентом? Мабуть. Але найкращі guardrails — це зелений CI, і цього немає.
- Немає observability. Трекінгу помилок немає в жодному клієнті. Постійних логів теж: Heroku тримає кільцевий буфер десь на 1 500 рядків веб. Раптовий баг у проді може зупинити фабрику, і швидко відреагувати неможливо.
- Звичка переписувати. У лютому 2026 почалось переписування фронтенду, а рефакторингові коміти — постійні резиденти їхньої git history знайдено. Коли впровадження буксує, команда переписує.
На цей список я витратив першу половину аудиту, бо кожен його пункт вимірюваний. Звісно, команда може полагодити їх усі, і швидко. Чат перетворюється на issue tracker за один механічний прохід агента. Набору тестів потрібна одна додаткова джоба в CI. Observability — це недорога покупка. Harness для кодових агентів — це кілька файлів, вивантажених із пам'яті агента бекендера. Переписування можна просто припинити. Нічого з цього не потребує значних грошей понад те, що вже витрачено, і все це швидко окупиться.
Усе це — друга петля безперервного покращення: робити кращою машину, яка будує продукт. А головна проблема сидить у першій петлі — зрозуміти, чи той продукт ми взагалі будуємо.
Що може тільки власник
Хоч як команда покращуватиме машину доставки, хоч як рефакторитиме й без того непоганий код, хоч скільки додаватиме фіч — вона не змінить єдиного визначального чинника успішного продуктового стартапу: зрозуміти, чого хочуть твої справжні клієнти і як їм це продати, поки не скінчились гроші. У власника буквально є дві справжні фабрики, які можуть перевірити всю продуктову обіцянку, дати цінні інсайти, зібрати зворотний зв'язок, показати реальну вартість інтеграції і намацати GTM. І все це ніяк не використовується.
Запустіть систему по-справжньому — у цеху, на живих людях, на справжній зарплаті — і не зупиняйтесь, доки щось не зламається. Ідіть і зламайте, саме так і вчаться!
Кожна спроба налагодити справжній виробничий запуск упирається в очікуване тертя. Ніхто й не сподівається, що впровадження нової ERP пройде гладко. Єдиний пілот на справжніх робітницях, ще в серпні 2025, розсипався у п'яти місцях знайдено. Але замість класичного «pivot or persevere» власник щоразу вирішує, що для нормального запуску потрібна ще одна фіча, ще одне переписування. Писати фічі, яких ніхто не перевіряє, — це марнота. Може, вони й цінні. Але це лише припущення власника. У цій петлі немає навчання, і це хрестоматійна дорога помилка продуктового бізнесу.
Усе, що контролює команда, полагодити можна. Єдине, від чого залежить доля продукту, — готовність власника наважитись на справжній виробничий запуск.
Стратегія уникання
Без справжнього зворотного зв'язку команда робить те, що добрі інженери вміють найкраще: вигадує і додає нові фічі, знаходить баги, переписує код, ітерує. Так, продукт стає багатшим на функції. Так, код стає кращим. Але продукт рухається в напрямку, правильність якого ніхто не перевіряв. Жодного справжнього болю ще не розв'язано. Тільки припущені.
Це класична позиція жаби, що вариться: інтегрувати рішення в справжні фабрики — це боляче, а додавати фічі й рефакторити наявний код — це комфортно. Але вода закипає: жоден бюджет не безмежний і жоден конкурент не беззубий.
На ринку є що завойовувати
А що з конкуренцією? Є де-факто галузевий стандарт, прийнятий по всій країні, — система «Швейка 8». Заявляється, що нею користуються понад 550 українських фабрик веб. У ній уже є та сама цехова петля, яку обіцяє продукт: штрихкодове сканування операції в момент її виконання. І онбординг там продають як окремий продукт — двомісячний платний пілот, вартість якого зараховують у покупку веб.
На щастя для SaaS ERP, «Швейка 8» — це підмодуль BAS (колишнього 1С), і продається вона тільки разом із ним: 13 500 грн за «Швейку 8» плюс 15 600 грн за «BAS Малий бізнес» на одне робоче місце веб. BAS в Україні заборонений для держсектора і критичної інфраструктури, бо платформу під ним вважають технологічно спорідненою з російською 1С веб. Він був достатньо дешевим і достатньо давнім, щоб здобути загальне поширення ще до російсько-української війни. Певно, кожен український бізнес був би радий піти з BAS, якби міг. Зазвичай не може. Або немає продукту за схожу ціну, або тертя від зміни ERP таке велике, що бізнес радше буде ризикувати користуватись системою, яку будь-якого дня можуть заборонити і для приватного використання (зареєстрований законопроєкт, що розширює заборону, зі штрафами до 2% річного обороту веб), або яка будь-якого дня може злити цінні бізнес-дані у росію.
Замінити BAS в Україні — це золота жила, і розв'язати цю задачу щодня намагаються буквально всі. Продукт SaaS ERP має бути кращим, мати швидший GTM і менше тертя, ніж у конкурента.
Що зробив би я
З боку команди — усе одно зробіть дешеві речі, бо вони знижують ціну рішення власника. Спершу зробіть збій видимим і безпечним: трекінг помилок у кожному клієнті, таймаут на резерв, ідемпотентний скан. Приблизно тиждень роботи — і найрозумніша причина власника зволікати вирішена. Далі треба перенести чат у трекер задач, запускати тести в CI і просто не починати нових переписувань.
З боку власника план єдиний: назвати дату, одну фабрику, один виріб, шість тижнів, паралельно з чинною системою обліку та зі щоденною звіркою, і не зупинятись на першому ж збої. Часу на нові фічі немає. Беріть те, що вже є, та ітеруйте від фідбеку з фабрики. Онбординг без тертя — це головний пріоритет. Ви не перевірите тертя онбордингу, не зробивши справжнього онбордингу. А тоді шукайте платних клієнтів. Після цього можна навіть іти по інвестиції, щоб підсилити розробку, маркетинг і продажі. Конкуренти не чекатимуть на ваш другий рефакторинг фронтенду.
Решту я виклав у розділі Політики та операції. Шість запропонованих політик. Я намагався зробити їх легкими для автоматизації і якомога менш обтяжливими:
- Історія чату перетворюється на трекер задач, а observability заводить issue сам.
- Гілку main охороняє зелений набір тестів, який уже є, і кожен прогін публікує покриття.
- Пілот на фабриці йде лише паралельно з чинним обліком.
- Сімдесят відсотків потужності команди йде на запуск, і щотижнева таблиця показує, куди вона пішла насправді.
- У продуктової обіцянки є названа відповідальна людина та дата перевірки; якщо перевірка не відбулась, обіцянку офіційно знімають.
- Нове переписування не починається, доки не записані його причина, критерій завершення і дата.
Стейкхолдер відповів, а ризик стрільнув
Я представив звіт бекенд-розробнику 19 серпня 2026 року, а 8 вересня попросив у нього відгук.
Власник застряг на терті онбордингу та знову вирішив відкласти запуск. Цього разу — на тому, як згрупувати обладнання фабрики. І він має рацію, що це важливо: у моделі обслуговування обладнання прив'язане до його підгрупи стейкхолдер. Замість того щоб прибирати тертя, команда робить чергове переписування (мобільний застосунок v2) і чергову фічу (рольову авторизацію) стейкхолдер.
Це і є той ризик, який я описував, і він спрацював. Переписування мобільного застосунку, нова фіча — і жодної працюючої фабрики: той самий патерн знову.
З боку команди це комфортне місце, поки є гроші. З боку продукту це програшна стратегія. Команда й далі робитиме фічі й переписуватиме їх, заробляючи нуль грошей і вивчаючи нуль інсайтів, бо єдине, із чого можна навчитися, — це зворотний зв'язок від справжньої фабрики, а фабрики в петлі навчання немає. Жаба вариться.
Арифметика додає різкості. Близько 100 тис. USD уже пішло в розробку виведено. Моє припущення: вихід на зовнішніх клієнтів забере щонайменше ще 50 тис. USD на маркетинг і продажі припущено. А єдиний актив, який міг би перетворити все це на продукт, — це дві діючі фабрики та власник, який знає галузь краще за будь-кого в команді, — не використовується ніяк. Усе інше команда збудує. Почати запуск може тільки власник.
Якщо це читає хтось із причетних: виправлення вітаються. Кожне твердження вище має джерело в повному аудиті, а відкриті питання перелічені в кінці.