# Засновнику, почни впроваджувати свій продукт зараз!

*Два роки хорошого коду, жодного інженерного процесу і жодного дня роботи в цеху*

> Нотатка · оновлено 2026-09-20 · 14 тверджень із джерелом · https://vit-panchuk.com/uk/writing/founder-start-adopting-your-product-now/

---
Двоє розробників два роки будували ERP для швейних фабрик. За гроші власника, у якого є дві діючі фабрики, готові цим користуватись. Він сподівається запустити з цього SaaS-рішення на всю країну, а то й на весь світ. Код здебільшого чудовий і робить свою справу. А от інженерного процесу довкола нього майже не було: ні трекера задач, ні спостережуваності, ні виразного інженерного лідерства.

Але все це можна виправити. Чого полагодити не вийде, і що може завалити все — це небажання власника наважитись на справжній виробничий запуск.

## Вступна сцена

Це другий опублікований приклад роботи [Engineering Strategy Framework](/uk/esf/). Попередній — опенсорсний e-commerce фреймворк Solidus: [текст](/uk/writing/the-moneypot-nobody-spends-vs-the-work-nobody-does/) і [повний аудит](/uk/reports/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 `[observed]`. А ще в SPA є написані ADR, PRD, CLAUDE.md та інші сліди сучасного harness engineering. У бекенда всього цього немає, але додати такі речі — це доволі швидко, це не масивна міграція коду.

## Процес — теж не проблема (хоча з ним безлад)

Друга моя здогадка — усе, що довкола коду. Ось там справді безлад.

- **Немає трекера.** Беклогом працює робочий чат. Ця фіча готова? Її протестували? Чого бракує? У кращому разі — шукай повідомлення в чаті, у гіршому — спробуй згадати, що казали в Google Meet.
- **Набір тестів, який нічого не охороняє.** CI є і вона запускає браузерні тести, але rspec-набір бекенду в CI відсутній. Бекендер проганяє його в себе на машині `[user]`. Чи проганяє його фронтендер, коли віддає бекендові фічі, написані з LLM-агентом? Мабуть. Але найкращі guardrails — це зелений CI, і цього немає.
- **Немає observability.** Трекінгу помилок немає в жодному клієнті. Постійних логів теж: Heroku тримає кільцевий буфер десь на 1 500 рядків `[web]`. Раптовий баг у проді може зупинити фабрику, і швидко відреагувати неможливо.
- **Звичка переписувати.** У лютому 2026 почалось переписування фронтенду, а рефакторингові коміти — постійні резиденти їхньої git history `[observed]`. Коли впровадження буксує, команда переписує.

На цей список я витратив першу половину аудиту, бо кожен його пункт вимірюваний. Звісно, команда може полагодити їх усі, і швидко. Чат перетворюється на issue tracker за один механічний прохід агента. Набору тестів потрібна одна додаткова джоба в CI. Observability — це недорога покупка. Harness для кодових агентів — це кілька файлів, вивантажених із пам'яті агента бекендера. Переписування можна просто припинити. Нічого з цього не потребує значних грошей понад те, що вже витрачено, і все це швидко окупиться.

Усе це — друга петля безперервного покращення: робити кращою машину, яка будує продукт. А головна проблема сидить у першій петлі — зрозуміти, чи той продукт ми взагалі будуємо.

## Що може тільки власник

Хоч як команда покращуватиме машину доставки, хоч як рефакторитиме й без того непоганий код, хоч скільки додаватиме фіч — вона не змінить єдиного визначального чинника успішного продуктового стартапу: зрозуміти, чого хочуть твої справжні клієнти і як їм це продати, поки не скінчились гроші. У власника буквально є дві справжні фабрики, які можуть перевірити всю продуктову обіцянку, дати цінні інсайти, зібрати зворотний зв'язок, показати реальну вартість інтеграції і намацати GTM. І все це ніяк не використовується.

Запустіть систему по-справжньому — у цеху, на живих людях, на справжній зарплаті — і не зупиняйтесь, доки щось не зламається. Ідіть і зламайте, саме так і вчаться!

Кожна спроба налагодити справжній виробничий запуск упирається в очікуване тертя. Ніхто й не сподівається, що впровадження нової ERP пройде гладко. Єдиний пілот на справжніх робітницях, ще в серпні 2025, розсипався у п'яти місцях `[observed]`. Але замість класичного «pivot or persevere» власник щоразу вирішує, що для нормального запуску потрібна ще одна фіча, ще одне переписування. Писати фічі, яких ніхто не перевіряє, — це марнота. Може, вони й цінні. Але це лише припущення власника. У цій петлі немає навчання, і це хрестоматійна дорога помилка продуктового бізнесу.

> Усе, що контролює команда, полагодити можна. Єдине, від чого залежить доля продукту, — готовність власника наважитись на справжній виробничий запуск.

## Стратегія уникання

Без справжнього зворотного зв'язку команда робить те, що добрі інженери вміють найкраще: вигадує і додає нові фічі, знаходить баги, переписує код, ітерує. Так, продукт стає багатшим на функції. Так, код стає кращим. Але продукт рухається в напрямку, правильність якого ніхто не перевіряв. Жодного справжнього болю ще не розв'язано. Тільки припущені.

Це класична позиція жаби, що вариться: інтегрувати рішення в справжні фабрики — це боляче, а додавати фічі й рефакторити наявний код — це комфортно. Але вода закипає: жоден бюджет не безмежний і жоден конкурент не беззубий.

## На ринку є що завойовувати

А що з конкуренцією? Є де-факто галузевий стандарт, прийнятий по всій країні, — система «Швейка 8». Заявляється, що нею користуються понад 550 українських фабрик `[web]`. У ній уже є та сама цехова петля, яку обіцяє продукт: штрихкодове сканування операції в момент її виконання. І онбординг там продають як окремий продукт — двомісячний платний пілот, вартість якого зараховують у покупку `[web]`.

На щастя для SaaS ERP, «Швейка 8» — це підмодуль BAS (колишнього 1С), і продається вона тільки разом із ним: 13 500 грн за «Швейку 8» плюс 15 600 грн за «BAS Малий бізнес» на одне робоче місце `[web]`. BAS в Україні заборонений для держсектора і критичної інфраструктури, бо платформу під ним вважають технологічно спорідненою з російською 1С `[web]`. Він був достатньо дешевим і достатньо давнім, щоб здобути загальне поширення ще до російсько-української війни. Певно, кожен український бізнес був би радий піти з BAS, якби міг. Зазвичай не може. Або немає продукту за схожу ціну, або тертя від зміни ERP таке велике, що бізнес радше буде ризикувати користуватись системою, яку будь-якого дня можуть заборонити і для приватного використання (зареєстрований законопроєкт, що розширює заборону, зі штрафами до 2% річного обороту `[web]`), або яка будь-якого дня може злити цінні бізнес-дані у росію.

Замінити BAS в Україні — це золота жила, і розв'язати цю задачу щодня намагаються буквально всі. Продукт SaaS ERP має бути кращим, мати швидший GTM і менше тертя, ніж у конкурента.

## Що зробив би я

З боку команди — усе одно зробіть дешеві речі, бо вони знижують ціну рішення власника. Спершу зробіть збій видимим і безпечним: трекінг помилок у кожному клієнті, таймаут на резерв, ідемпотентний скан. Приблизно тиждень роботи — і найрозумніша причина власника зволікати вирішена. Далі треба перенести чат у трекер задач, запускати тести в CI і просто не починати нових переписувань.

З боку власника план єдиний: назвати дату, одну фабрику, один виріб, шість тижнів, паралельно з чинною системою обліку та зі щоденною звіркою, і не зупинятись на першому ж збої. Часу на нові фічі немає. Беріть те, що вже є, та ітеруйте від фідбеку з фабрики. Онбординг без тертя — це головний пріоритет. Ви не перевірите тертя онбордингу, не зробивши справжнього онбордингу. А тоді шукайте платних клієнтів. Після цього можна навіть іти по інвестиції, щоб підсилити розробку, маркетинг і продажі. Конкуренти не чекатимуть на ваш другий рефакторинг фронтенду.

Решту я виклав у розділі [Політики та операції](/uk/reports/saas-erp/#політики-та-операції). Шість запропонованих політик. Я намагався зробити їх легкими для автоматизації і якомога менш обтяжливими:

1. Історія чату перетворюється на трекер задач, а observability заводить issue сам.
2. Гілку main охороняє зелений набір тестів, який уже є, і кожен прогін публікує покриття.
3. Пілот на фабриці йде лише паралельно з чинним обліком.
4. Сімдесят відсотків потужності команди йде на запуск, і щотижнева таблиця показує, куди вона пішла насправді.
5. У продуктової обіцянки є названа відповідальна людина та дата перевірки; якщо перевірка не відбулась, обіцянку офіційно знімають.
6. Нове переписування не починається, доки не записані його причина, критерій завершення і дата.

## Стейкхолдер відповів, а ризик стрільнув

Я представив звіт бекенд-розробнику 19 серпня 2026 року, а 8 вересня попросив у нього відгук.

Власник застряг на терті онбордингу та знову вирішив відкласти запуск. Цього разу — на тому, як згрупувати обладнання фабрики. І він має рацію, що це важливо: у моделі обслуговування обладнання прив'язане до його підгрупи `[user]`. Замість того щоб прибирати тертя, команда робить чергове переписування (мобільний застосунок v2) і чергову фічу (рольову авторизацію) `[user]`.

Це і є той ризик, який я описував, і він спрацював. Переписування мобільного застосунку, нова фіча — і жодної працюючої фабрики: той самий патерн знову.

З боку команди це комфортне місце, поки є гроші. З боку продукту це програшна стратегія. Команда й далі робитиме фічі й переписуватиме їх, заробляючи нуль грошей і вивчаючи нуль інсайтів, бо єдине, із чого можна навчитися, — це зворотний зв'язок від справжньої фабрики, а фабрики в петлі навчання немає. Жаба вариться.

Арифметика додає різкості. Близько 100 тис. USD уже пішло в розробку `[inferred]`. Моє припущення: вихід на зовнішніх клієнтів забере щонайменше ще 50 тис. USD на маркетинг і продажі `[assumed]`. А єдиний актив, який міг би перетворити все це на продукт, — це дві діючі фабрики та власник, який знає галузь краще за будь-кого в команді, — не використовується ніяк. Усе інше команда збудує. Почати запуск може тільки власник.

Якщо це читає хтось із причетних: виправлення вітаються. Кожне твердження вище має джерело в [повному аудиті](/uk/reports/saas-erp/), а [відкриті питання перелічені в кінці](/uk/reports/saas-erp/#чого-ми-не-знаємо).