SaaS ERP

Два роки розробки, дві пари рук, 95,71% покриття тестами, і жодного дня реальної роботи на жодній із двох фабрик, які власник має напоготові.

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

Мета ширша за запуск: обидві фабрики власника, продуктизація і продаж системи як SaaS зовнішнім клієнтам стейкхолдер. У цій рамці вартість наповнення даними перестає бути разовою перешкодою і стає юніт-економікою кожного наступного клієнта.

Що і за який період дивились: репозиторій main станом на 2026-08-12, експорт Telegram за 2024-05-13 → 2026-08-10 (5 735 повідомлень), веб-огляд 2026-08-13. Тести прогнали і покриття виміряли 2026-08-13 на окремій базі. Доступу до GitHub Actions і до репозиторію мобільного застосунку не було; там, де це змінює висновок, сказано прямо. Пізніше додалось одне свідчення зсередини команди. 2026-08-19 автор представив звіт BE-розробникові, а 2026-09-08 попросив у нього відгук стейкхолдер. Що саме ця розмова зрушила, записано в журналі рішень, у K14що змінила розмова з BE-розробником.

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

Майже половина тверджень стоїть на прочитаному в коді, git-історії та експорті чату, ще п'ята частина — на веб-джерелах. Для питань факту це міцна основа. Слабке місце в іншому: власника фабрик, головну дійову особу цієї історії, аудит не опитував. Слова стейкхолдера тут мають два джерела. Більшість сказав автор аудиту — людина поруч із проєктом, а не учасник команди. Решту, датовану 2026-09-08, — BE-розробник, якому звіт представили 2026-08-19.

Початок тут

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

Що таке SaaS ERP

Це ERP для швейного виробництва: система, яка веде виріб від замовлення до відвантаження і рахує відрядну зарплату швачкам. Не крамниця, не облік — саме керування цехом.

Технічно це монорепозиторій із чотирьох частин знайдено:

• Rails 8.1 API — 138 моделей, 86 контролерів, 442 міграції. Уся доменна логіка.
• frontend/ — перший веб-інтерфейс на antd. Виведений з експлуатації в липні 2026, лишається в git як довідковий матеріал.
• frontend_v2/ — другий веб-інтерфейс, React 19 + власна дизайн-система. Основна лінія роботи з лютого 2026. знайдено
• docs/ — сайт документації на Next.js із PRD, user stories і ADR. знайдено

Плюс мобільний застосунок на React Native в окремому репозиторії — саме він несе обіцянку продукту.

Обіцянка продукту

Її сформулював автор аудиту стейкхолдер так: робітниця в цеху має мобільний застосунок, підходить до надрукованого документа з QR-кодом, сканує його, і отримує саме той перелік операцій, який має робити сьогодні.

Це не декоративна деталь. Це і є те, за що фабрика платить: керування в реальному часі замість обліку постфактум.

Дійові особи

• Власник — не з IT. Носій предметної експертизи рівня технолога: диктує модель даних, оперує поняттями 1С, перелічує канонічні документи швейного виробництва напам'ять знайдено. Має дві діючі швейні фабрики, з яких можна стартувати стейкхолдер.
• FE-розробник — фронтенд. 2 553 коміти (79% усіх). знайдено Побудував обидва веб-інтерфейси, мобільний застосунок, CI, документацію, ADR, e2e-набір і agent harness. Фактично комітить у backend більше, ніж backend-розробник.
• BE-розробник — backend на Ruby. 692 коміти знайдено. Володіє інфраструктурою Heroku стейкхолдер.
• Автор аудиту — у проєкті не працює: комітів не має, у робочому каналі не пише знайдено. Він задав вектор дослідження, висував гіпотези і виправляв висновки по ходу роботи.

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

Як читати позначки

Коди реєстрів

PL політики · S стратегії в силі · RC першопричини · R ризики · D борги · C активи · E швидкі перемоги · B ставки · K рішення · P пре-мортем · Q відкриті питання. Кожна згадка коду несе однорядкову пам'ятку, щоб не доводилось шукати, що це було.

Хронологія

Політики та операції

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

Одна умова визначає форму всіх шести. Мандату в проєкті немає: власник не має технічної експертизи, BE-розробник за власним визнанням не бере на себе покращення машини й інженерне лідерство, FE-розробник — найкращий кандидат у лідери, але без глибокої BE-експертизи, і саме він щойно питав про пошук роботи RC2вакуум технічного лідерства. Тому жодна політика тут не розраховує на те, що хтось наполягатиме. Ті, що мусять спрацювати напевно, зроблені рамками CI: вони не питають дозволу. Ті, що рамками стати не можуть, свідомо ослаблені до рекомендації. Приписова політика, яку нікому виконувати, це театр згоди, а не стратегія.

Бізнес-контекст: гроші, яких менше, ніж здається

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

Оплата планується наперед («Планую до 05.03 зробити оплату 1750 у.о.»), існує величина «зароблено, але не виплачено» (BE-розробник випадково затер формулу, яка її рахує, у спільній Google-таблиці), а поняття заборгованості достатньо живе, щоб її закриття оголошували окремо: «Заборгованість відсутня» знайдено. Суми коливаються: 85 386 грн за місяць одному розробнику в серпні 2025 (≈2 000 USD), 1 750 у.о. у лютому 2025, 500 у.о. у червні 2026. Квитанції надходять парами приблизно щомісяця, з розривом майже на п'ять місяців між квітнем і вереснем 2025.

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

Але груба арифметика варта уваги: ≈2 000 USD × 2 розробники × 27 місяців дає близько 100 тис. USD уже витрачених. Це приблизно дорівнює гранту, який FE-розробник знайшов у грудні 2025 — з умовою «мати вже хоч якусь запущену базову версію продукту (в ідеалі з доходом)». Тобто зовнішні гроші, які могли б подвоїти ресурс проєкту, лежать за тими самими дверима, що й запуск.

Попереду стаття, якої немає в жодній таблиці: вихід на зовнішніх клієнтів потребуватиме маркетингу. Автор аудиту оцінює його щонайменше в 50 тис. USD припущено. Це оцінка порядку, а не розрахунок, але вона показує масштаб: до продукту на ринку треба вкласти ще щонайменше половину вже вкладеного.

Стартап-грант до 100 тис. USD вимагає запущеної версії продукту, бажано з доходом. Тред прожив тиждень у грудні 2025 і згас після перенесеної зустрічі. За наступні сім місяців слово «грант» в експорті не зустрічається жодного разу.

Продукт: обіцянка, яку перевіряли один раз

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

Реалізація цьому відповідає. QR несуть саме ті два документи, що є документами партії: маршрутний лист і карта крою, кожен із payload { id, type } на етикетці 100 × 50 мм разом із кодом, виробом, кольором, розміром і плановою кількістю знайдено. Специфікація QR не має і не повинна: вона є шаблоном виробу, а не завданням на конкретну партію.

Тобто задум і код тут збігаються. Розходиться інше — те, що відбувається після сканування.

Перевірка відбулась у серпні 2025, на живих робітницях, один раз. Петля розсипалась у п'яти незалежних місцях.

Решта три: після генерації етикетки збивається послідовність друку; під час сканування на екрані лишається частина попереднього меню; QR несе прив'язку до місця розташування, через що маршрутний лист, створений в одному підрозділі, не відкривався у зміні того ж підрозділу. Серверна валідація прив'язки обладнання до підрозділу з'явилась 2026-07-23 — через одинадцять місяців після того, як власник про це написав.

І ще одна умова, яку власник назвав ще у березні 2025: петля вимагає двох сканувань — обладнання і документа — плюс відкритої зміни в правильному підрозділі. «Кожного разу сканувати одну і ту саму річ не актуально».

У травні 2025 розробник спроєктував «резервну функцію, щоб адмін міг вручну внести дані про виконанні процеси». У червні 2026 вона отримала повний CRUD процесів зміни у вебі й сім e2e-специфікацій. Мобільна половина петлі — та, що несе обіцянку — з серпня 2025 на людях не перевірялась.

Організація: у кімнаті немає дорослого

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

Розкладка ролей проти потреби:

Із цього випливають три речі, і всі три структурні, а не персональні.

Стеля припису низька. Немає людини, яка одночасно має мандат і готова застосовувати наслідки. Тому приписова політика, що спирається на людську наполегливість, провалює критерій виконуваності за визначенням — звідси форма PL2main захищений зеленим rspec: рамки, які не питають дозволу.

Інфраструктура і воля до її покращення лежать у різних руках. Heroku належить BE-розробнику; безперервне покращення машини — не його зона за власним визнанням. Будь-яка політика, що вимагає змін у деплої чи CI, має або переїхати до FE-розробника разом із доступом, або лишитись невиконаною.

Знаннєвий розрив односторонній і повний. Поза полем зору BE-розробника перебуває вся інженерна надбудова: устрій CI, ADR-и, PRD, набір із 303 e2e-тестів, harness на 426 рядків стейкхолдер. У зворотний бік асиметрії немає: FE-розробник комітить у backend 1 089 разів і робить це власним агентом. Тобто майже всі інженерні активи проєкту створені однією людиною і відомі лише їй, і це та сама людина, яка щойно запитала про пошук роботи.

Інженерія: висока якість без жодних рамок

Найважливіше, що варто сказати про цей код: він хороший. Це не проєкт із низькою культурою, який треба рятувати. Це проєкт із високою культурою, чиї результати нікуди не підключені.

• 95,71%покриття backend від rspec, 6 114 прикладів
• 79,05%покриття backend від e2e, 303 тести
• 80,72%покриття frontend від e2e
• 0з цього було коли-небудь виміряно до цього аудиту

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

Два набори міряні окремо. Rspec: 6 114 прикладів, 95,71% рядків і 82,12% гілок. E2e, знято одним прогоном 2026-08-14 (303 passed): backend 79,05% рядків (7 193 / 9 099) і 45,56% гілок, frontend 80,72% рядків (21 634 / 26 800) знайдено.

Читати їх треба разом. 79% рядків backend від браузерних тестів — це багато: 303 тести ганяють реальні доменні сценарії, а не димові перевірки. Розрив по гілках (45,56% проти 82,12%) показує здоровий поділ праці: e2e йде щасливими шляхами, юніт-специфікації беруть гілки помилок. Тобто backend прикритий із двох незалежних боків.

І тут потрібне уточнення, бо воно змінює адресу проблеми. E2e в CI виконується: у test.yml є джоба E2E Tests, яка піднімає бекенд через docker compose, чекає готовності API, розгортає базу і запускає Playwright знайдено. Отже бекенд у CI перевіряється — але з браузера, по щасливих шляхах, із покриттям гілок 45,56%.

Не виконується в CI саме rspec: набір із 6 114 прикладів, який тримає 82,12% гілок, не запускається жодного разу. Це не «тести не підключені» — це «підключений той із двох наборів, який найгірше ловить помилкові гілки, а той, що ловить їх найкраще, мовчить».

Шлях до цієї цифри сам є знахідкою. Дві спроби провалились, і кожна показала окремий дефект:

1. Bootsnap несумісний з інструментуванням покриття — усі 308 файлів падають на завантаженні.
2. rspec не стартує у власному тестовому стеку проєкту: сервіс api тримає ту саму базу, яку DatabaseCleaner очищає в before(:suite), і вони взаємно блокуються.

Перший вимір після обходу дав 47,94%, і був хибним: жоден приклад не виконався, число відображало виконання коду під час завантаження Rails. Викрила це метрика гілок: 0,36%.

Спостережуваність

Її немає. Перевірено Gemfile, package.json, frontend_v2/package.json: жодного Sentry, Bugsnag, Rollbar, Honeybadger, AppSignal, Datadog, New Relic знайдено, підтверджено замовником стейкхолдер.

Є /up (застосунок піднявся), логи у stdout із тегом request_id без агрегації — Logplex тримає буфер на ~1 500 рядків і до тижня, тож без drain вони зникають веб; і скрипт, що вивантажує сорсмапи в S3 без приймача помилок: заготовка під розшифровку стектрейсів, які нікуди не надсилаються.

Механізм, що зупиняє цех

Це найважливіша знахідка інженерного розділу, і вона стає видимою лише в рамці «це фабрика». ProcessItem валідує на створенні:

def reserved_quantity
operation.process_items.where(sheetable_id:).where.not(id:).sum do |p_i|
  p_i.finished? ? p_i.actual_quantity || 0 : p_i.planned_quantity || 0
end
end

def allowed_quantity
@allowed_quantity ||= (sheetable.planned_quantity || 0) - (sheetable.defected_quantity || 0) - reserved_quantity
end

Читається так: незавершений процес тримає резерв на всю свою планову кількість. Звільнити його можна двома способами — завершити процес або видалити його, а видалення закрите правом processes:delete, тобто доступне адміністратору, не швачці. Ні таймауту, ні автоматичного звільнення немає.

Ідемпотентності на створення теж немає. Подвійне сканування — рівно те, що робить людина, коли перший скан не дав видимої реакції, тобто рівно те, що сталося в серпні 2025 — створює другий процес і з'їдає резерв удруге.

Обидва сценарії вже трапились: «Працівник одночасно запустив 2 процеса на виконання» (2025-05-23) і, у липні 2025, робота, яку зробили і не дали закрити: «показало всі п'ять пачок по 50 та не дало нам закрити роботу».

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

Стратегія, яка вже діє

Перед тим як пропонувати стратегію, звіт документує ту, що вже керує рішеннями, записана вона чи ні. Тут вона є, і вона послідовна.

Рядки оцінюють одне одного. S4дисципліну задає фронтенд — найздоровіша стратегія проєкту — існує тому, що одна людина взяла її на себе; S5backend-контекст у приватній пам'яті є її дзеркальною відсутністю на іншому боці тієї ж кодової бази. А S2відомий провал тесту — норма є тим, що робить S1якість добровільна марною: чудовий набір тестів, який ніщо не запускає, захищає рівно нікого.

Першопричини

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

Реєстр ризиків

Ранжовано за шкодою × ймовірністю × помітністю × вартістю відновлення. Низька помітність піднімає пріоритет: тихий збій небезпечніший за гучний тієї ж сили.

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

Реєстр боргів

Ризик може статися; борг оплачується вже зараз, у кожному циклі.

Реєстр активів

Активи, які платитимуть у кожному наступному циклі. Актив вважається підтвердженим лише тоді, коли ним справді скористалися повторно, тому проєктні записи позначені окремо.

Швидкі перемоги

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

Десять записів, сумарно ≈4 агенто-дні. Кожен закриває названий у звіті борг, і жоден не потребує рішення власника. Номер E1 лишається порожнім: та перемога знята, а номери не перевикористовуються, щоб давніші посилання не зʼїхали.

Стратегічні ставки

Ставки оцінено проти прийнятої відповіді на відкрите питання Q4скільки місяців можна фінансувати: припускаємо, що запас часу обмежений і невеликий. Це положення випливає з наявних слідів, а не з заяви; якщо власник відповість інакше, порядок треба перерахувати.

Відбір: три ставки на квартал

Робимо B1зробити збій помітним і безпечним, B2один виріб, паралельний прогін і B4призначити відповідального за інженерну машину.

Чому чекають решта:

B3агентний онбординг як механізм чекає, і це головна зміна порядку відносно вихідної гіпотези. Вектор, заданий автором аудиту, був саме онбординг, і докази його підтверджують сильніше, ніж очікувалось: власник сам виміряв 30 хвилин на специфікацію і сам попросив виправлення. Але дешевий вхід у систему, яка вміє тихо заблокувати роботу і не вміє про це повідомити, лише швидше приводить до незахищеної точки відмови. Спершу безпека, потім вартість входу. При цьому мінімальний онбординг не чекає: він входить усередину B2один виріб, паралельний прогін як завантаження одного виробу. Механізмом він стає після того, як петля довела свою роботу. Тоді його масштабують на асортимент, а не будують наосліп.

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

• бюджет обмежений і без того R4гроші закінчаться раніше за запуск;
• покриття автоматичними тестами високе з обох боків (C195,71% від rspec, C879% backend і 81% frontend від e2e), тож найдешевший клас дефектів уже ловить машина;
• і головне — немає інфраструктури, у якій QA працює. Без issue tracker йому нема куди класти знайдене і нема де бачити стан фічі чи бага D6Telegram як дошка задач. Найняти тестувальника в проєкт без трекера означає завести четвертий потік повідомлень у той самий чат.

Тому корисна саме разова консультація: досвідчений QA дивиться на наявні 303 тести і каже дві речі, яких зсередини не видно — чи правильна методологія і яких критичних шляхів бракує. Набори e2e, написані розробниками, регулярно містять фундаментальні прогалини, очевидні будь-якому тестувальнику й невидимі авторам. Це вписується в бюджет, не потребує трекера і дає найбільше на вкладену годину. Після PL1історія чату конвертується в Issue Tracker питання про постійного QA слід відкрити знову: тоді інфраструктура вже буде.

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

B6міграція v1→v2 завершена зі списку знято: команда зробила це сама і зробила правильно. Міграція мала названу причину, рамки якості на кожній фазі та явне перемикання продакшну.

Швидкі перемоги в цьому відборі не беруть участі, вони йдуть паралельно пакетом.

Найширше заперечення проти головної ставки

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

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

Друге заперечення сильніше. Можливо, паралельний облік сам знімає ризик R1конвеєр стає і ніхто не дізнається, і тоді B1зробити збій помітним і безпечним до пілоту не потрібна. Почасти це правда: він справді робить збій нефатальним. Але він не робить його видимим. Без трекінгу помилок команда дізнається про дефект від власника наступного дня, і на двотижневому пілоті цикл виправлення зʼїсть половину вікна.

Пріоритети інвестицій

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

Стратегія еволюції

Дві здатності, на які спирається стратегія, варто розмістити на осі дозрівання, бо від їхнього дрейфу залежить вибір «будувати чи чекати».

Вилучення даних із документів — з custom у product і далі до commodity, швидко веб. Ринок уже пропонує готові рішення (OneSchema, Unstract, Spreadsheet Agent від LlamaIndex). Висновок для B3агентний онбординг: не будувати парсер. Кастомною лишається лише частина «відобразити на модель SaaS ERP», і вона кастомною й залишиться, бо схема тут власна.

Спостережуваність — давно commodity. Будувати щось своє тут було б класичною помилкою «Build на комодиті», тому E4Sentry у backend і фронтенди є покупкою, а не розробкою.

Нормативи часу на швейні операції (GSD і подібні) — product, ліцензійний веб. Але для цього проєкту вони не потрібні: нормативи вже є в голові власника, а для одного виробу вже заведені в систему. Це рідкісний випадок, коли внутрішній актив дорожчий за ринковий.

Ринок: ніша зайнята, і зайнята міцніше, ніж здавалося

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

Світові гравці, побудовані під ту саму задачу

Найближчий конкурент робить рівно те, що обіцяє SaaS ERP. Scan ERP позиціонується на малі й середні CMT-фабрики (20–500 операторів) і будується навколо партій, операцій, відрядної оплати та QR-сканування. Ціна публічна і низька: $5 за машину на місяць або $0,001 за відстежену одиницю, що дешевше, без плати за користувачів і з необмеженою кількістю операторів; впровадження — два тижні веб. Для фабрики на 50 машин це близько $250 на місяць.

Поруч ширший ряд: WFX Cloud ERP (середній сегмент, ціна лише за запитом), Kladana (від $5 на місяць, є безкоштовний план), Datatex, MRPeasy, відкритий ERPNext, а зверху Infor CloudSuite Fashion і NetSuite у складанні під cut-make-trim. Для порівняння, впровадження SAP S/4HANA чи Oracle у цій галузі коштує від $50 тис. і триває 6–12 місяців веб.

Сам ринок росте: ПЗ для дизайну і виробництва одягу оцінюють у $2,95 млрд у 2026 році з CAGR близько 11%, а сегмент apparel management — у $2,25 млрд у 2025 з прогнозом $4,36 млрд до 2034 веб.

Український контекст: хто вже стоїть у цій ніші

Локальне галузеве рішення існує, воно зріле і воно не порожнє. «Швейка 8» веде повний цикл від техкарти до продажу, має робоче місце технолога, три режими розцінки операцій, завдання на розкрій, передачу в цех і розподіл між швачками — тобто буквально предметне ядро SaaS ERP. Постачальник заявляє понад 550 українських підприємств серед користувачів веб.

Два уточнення, які варто було зробити раніше, бо вони прибирають дві уявні переваги SaaS ERP.

Перше: цехове сканування там уже є. Сторінка продукту описує це прямо — «штрихкодування техоперацій є у готовому рішенні і найчастіше використовується на виробництвах, де фіксація виконання операції проходить у момент виконання операції» веб. Це та сама петля, яку SaaS ERP обіцяє мобільним застосунком: працівник фіксує операцію в момент її виконання. Отже мобільна петля R3петля скану може досі не працювати не є відмінністю — це очікуваний елемент, який у конкурента відвантажений, а в SaaS ERP непідтверджений.

Друге: онбординг там продуктизований і платний. Він називається «Примірка» і виглядає так: 2 місяці, 10 годин навчання за 6–7 віддалених записаних сесій, 11 000 грн — з порожньою базою на сервері клієнта, побудовою схеми обліку разом із ним і наскрізним прикладом на його власних даних. Оплата зараховується в рахунок покупки: повністю від 10 робочих місць, наполовину від 3 до 9 веб.

Ціна самого продукту: «Швейка 8» коштує 13 500 грн, але купується тільки спільно з «BAS Малий бізнес» за 15 600 грн, разом 29 100 грн за одне робоче місце веб.

Що таке BAS і чому заборона діє слабше, ніж хотілося б

BAS — це набір конфігурацій на платформі BAF (Business Automation Framework) польської компанії NetHelp, що зʼявилася 2018 року і яку описують як «наближення до платформи 1С для українського ринку». Системи, що стояли на 1С:Підприємство, після 2021 масово перейшли на BAF і взяли назву BAS веб. Тобто BAS створювався саме як зʼїзд із 1С — і саме тому переїзд туди дешевий: та сама парадигма, ті самі інтегратори, та сама звичка бухгалтера, готові інструменти перенесення довідників і залишків.

Далі цей зʼїзд сам потрапив під заборону. Хронологія: санкції РНБО проти продуктів BAS ще у 2020; квітень 2023 — санкції проти 1С на десять років, до 2033; 18 липня 2025 — законопроєкт №13505 про заборону ворожих програмних продуктів зі штрафами до 2% річного обороту; 9 січня 2026 Держспецзвʼязку опублікувала перелік забороненого ПЗ, і до кінця місяця в ньому було близько 27 продуктів на BAF, включно з BAS ERP і BAS Бухгалтерія КОРП. Підстава — «технологічна спорідненість» із 1С веб.

І тут межу треба тримати чітко, бо від неї залежить, чи є взагалі вікно. Заборона стосується держсектора і критичної інфраструктури, а не будь-якого приватного підприємства. Приватна швейна фабрика під неї не підпадає. Законопроєкт №13505, який поширив би штрафи ширше, зареєстровано, але не ухвалено веб. Тобто юридичного примусу, який виштовхнув би фабрику зі «Швейки 8», сьогодні немає — є репутаційний і регуляторний фон.

Є ще один поворот, який працює проти нас. Перенесення з 1С проходить гладко на типових конфігураціях, а ламається на доопрацьованих і галузевих веб. «Швейка 8» — рівно такий випадок. Це означає, що фабрика на ній прикута до неї не тільки звичкою, а й вартістю виходу — і цей замок тримає її від переходу куди завгодно, включно з SaaS ERP. Липкість працює на того, хто вже всередині.

Стан самої галузі

Вона стискається, але переорієнтовується. Зайнятість у легкій промисловості впала зі 133 тисяч у 2019 до 91 тисячі у 2025; від 2022 року 128 підприємств релокувалися до Закарпаття; виробники скаржаться на зростання цін на електроенергію, паливо і сировину. Водночас галузева асоціація описує стратегію як «стати ательє Європи», тобто рух у контрактне виробництво на європейські бренди веб.

«Швейка 8» заявляє понад 550 українських підприємств, має штрихкодування техоперацій у готовому рішенні і продуктизований платний онбординг «Примірка» (2 місяці, 11 000 грн, зараховується в покупку). Мобільна петля в цеху — не відмінність SaaS ERP, а очікуваний елемент, який у конкурента відвантажений, а тут непідтверджений.

Перелік забороненого ПЗ від 9 січня 2026 стосується держсектора і критичної інфраструктури; законопроєкт №13505 зі штрафами не ухвалено. Водночас BAF проєктувався як наближення до 1С, тож переїзд 1С → BAS дешевший за переїзд 1С → SaaS ERP, і хвиля міграції тече переважно туди.

Що з цього випливає для стратегії

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

Ціна задана ринком, і вона низька. $5 за машину на місяць у Scan ERP і 29 100 грн разово за робоче місце у «Швейки 8» означають, що юніт-економіка SaaS ERP мусить зійтися при кількох сотнях доларів на фабрику на місяць.

А ось тут — несподіване і найкорисніше з усього розділу. Конкурент, що працює в цій ніші роками, витрачає на онбординг два місяці й бере за це гроші. Ринок, отже, не вважає довгий онбординг вадою: він вважає його послугою. Це прямо коригує RC5вхід дорожчий за вихід. Проблема SaaS ERP не в тому, що онбординг довгий — за галузевою міркою він нормальний. Проблема в тому, що він не має ані визначеного кінця, ані ціни, ані перевірки придатності: у «Примірці» є порожня база, шість сесій, наскрізний приклад на даних клієнта і дата, коли все закінчується. У SaaS ERP немає жодного з цих чотирьох елементів.

Це змінює зміст B3агентний онбординг як повторюваний механізм. Ставка лишається, але її мета інша: не «звести онбординг до нуля», а зробити його обмеженим, вимірюваним і продаваним. Агент тут скорочує частину роботи, а не скасовує процес — і навіть скорочений процес потребує наскрізного прикладу на даних клієнта, бо саме він є перевіркою придатності й джерелом зворотного звʼязку.

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

Куди має цілитися агентний онбординг

Дотепер B3агентний онбординг як повторюваний механізм описувався як розбір того, що фабрика тримає в себе: Excel, зошити, PDF-техкарти. Цей розділ дає підстави замінити цільове джерело, і заміна міняє характер ставки.

Реалістичний зовнішній клієнт SaaS ERP — це не фабрика, яка нічого не автоматизувала. Це фабрика, яка вже сидить на «Швейці 8»: у ніші 550 таких, у них уже є структуровані дані, і в них уже є привід озирнутися. Тому агентний онбординг варто проєктувати з дугою «міграція зі „Швейки 8“», а не «розбір паперу».

Різниця не косметична — вона в тому, чи є ця робота одноразовою, чи повторюваною:

Саме тут агент дає непропорційну користь. Структури даних платформи 1С/BAF відомі своєю непрозорістю: фізичні таблиці мають технічні імена на кшталт SC327 і SP330, службові поля перемішані з бізнесовими, документ складається із шапки й кількох табличних частин веб. Людині писати такий імпортер довго й нудно; агентові — це рівно та задача, яку він робить добре: дослідити схему, побудувати відображення, показати результат на наскрізному прикладі. І, на відміну від розбору PDF, це відображення пишеться один раз на всю нішу.

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

Куди це веде: дві фабрики, продуктизація, зовнішні клієнти

Кінцева мета власника ширша за запуск: вийти на обидві свої фабрики, продуктизувати систему і продавати її як SaaS реальним клієнтам стейкхолдер. Це змінює вагу однієї зі ставок, тому варто сказати прямо.

Що для цього вже є. Мультитенантність не декларативна, а робоча: 45 із 114 моделей несуть multi_tenant, тенант ставиться з current_user.company на кожен запит у base_controller, а створення компанії тягне за собою after_create, які засівають типові права, одиниці виміру й системний тип матеріалу «Тканини» знайдено. Тобто ізоляція даних і базовий провіженинг нового клієнта вже написані — це рідкість для проєкту, який ще не запустився.

Чого немає. Самореєстрації: створення компанії закрите перевіркою superuser_check знайдено. Білінгу, тарифів і всього, що робить SaaS бізнесом, у коді немає взагалі.

Головний наслідок, і він міняє пріоритет. У моделі «одна власна фабрика» вартість наповнення даними є разовою перешкодою на шляху до запуску. У моделі SaaS вона стає юніт-економікою кожного клієнта: 30 хвилин на специфікацію множаться на асортимент кожної нової фабрики, і платить за це або клієнт своїм часом, або власник своїм. Те, що зараз виглядає як внутрішній інструмент B3агентний онбординг, у цій рамці є частиною продукту, і саме тією, від якої залежить, скільки коштує підключити наступного клієнта.

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

Лог рішень

Пре-мортем

Рік потому план не спрацював. Ось як — від найімовірнішого.

Список спостереження

Чого ми не знаємо

Впорядковано за впливом на рішення: перше питання рухає найбільше.

Q6у якому вигляді й обсязі власник тримає дані — у якому вигляді й у якому обсязі власник тримає свої дані. Це визначає, чи B3агентний онбординг є двома тижнями роботи чи продуктовим модулем. Потрібні числа: скільки виробів в активному асортименті на кожній фабриці, скільки операцій на виріб, скільки працівників і машин. І формат: техкарти — це Excel, 1С, PDF чи папір? Єдиний зразок, який мав аудит, виявився експортом із самої системи стейкхолдер, тож зразка вихідних даних власника в аудиту немає зовсім. За 27 місяців у чат не надіслали жодного файлу Excel, тож припущення про «книги в Excel» досі неперевірене припущено, і найдорожче з усього неперевіреного.

Q8чи полагоджено петлю скану і чи перевіряли на людях — чи полагоджено петлю скану і чи проганяли її на людях після серпня 2025. Рухає R3петля може досі не працювати з невідомої в низьку або високу. Аудит відповісти не може: репозиторію мобільного застосунку на машині немає. Це названа межа цього звіту, а не пропуск. З вересня 2026 мобільний застосунок переписують стейкхолдер, тож відповідь стосуватиметься вже нового застосунку — і петлю варто прогнати на людях до того, як переписування оголосять завершеним.

Q4скільки місяців власник готовий фінансувати — скільки місяців власник готовий фінансувати і що станеться далі. Одна ця відповідь визначає, чи рекомендація читається як «послідовно за два квартали», чи як «один цех, один виріб, шість тижнів, і не більше».

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

Де питати. Q6, Q4 і Q7 — безпосередньо у власника, у тій самій Telegram-групі, яка лишається єдиним живим каналом проєкту. Q8 — у FE-розробника, разом із доступом до репозиторію Mobile/.