Кейс: FinDesk ERP, прототип обліку з ШІ

Бухгалтер пробачає системі незручний інтерфейс і відсутню функцію. Неправду він не пробачає. Показати чуже число замість свого, написати «прийнято ДПС», коли нічого не надсилалось, намалювати форму, схожу на затверджений бланк, і довіру вже не повернути жодною демонстрацією. З цього принципу ми почали проєктування FinDesk ERP, української облікової системи з ШІ-автопілотом. Цей кейс про те, як зробити прототип, якому повірять 30 бухгалтерів пілоту.

Задача

Ринок обліку в Україні тримається на BAS і звичці. Щоб бухгалтер розглянув нову систему, вона має закривати щоденну роботу на рівні звичної програми і забирати помітно більше рутини. Задача першого етапу: зробити клікабельний прототип усієї системи, який:

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

Рішення

Прототип як специфікація

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

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

Десять правил довіри

Робота над прототипом іде за коротким набором незламних правил. Кілька найважливіших:

1. Картка документа показує лише дані активної компанії. Якщо документ не знайдено, бухгалтер бачить чесний екран «не знайдено». Підставити демо-документ замість відсутнього заборонено: ця помилка траплялась тричі, і кожного разу бухгалтер бачив чужого контрагента і чужу суму.
2. Система не стверджує того, чого не робить. Поки немає реального транспорту в податкову, на екрані немає слів «прийнято» чи «зареєстровано» без позначки «демо». Друковані форми, не звірені з наказом, мають плашку «макет форми».
3. Кожна кнопка відповідає на клік. Або працює, або повідомляє, що функція запланована. Мовчазна кнопка читається як поломка.
4. Число похідне. Якщо величина є в іншому місці, вона імпортується, а не копіюється. Реквізити, оборотно-сальдова відомість, баланс, податкові константи і зарплата мають одне джерело кожне.
5. Жодної норми права числом у коді. Ставки, ліміти і строки живуть у константах з посиланням на статтю закону.
6. Проведений документ спершу розпроводиться. Пара «Провести» і «Розпровести» симетрична, як звикли бухгалтери, і кнопки дій стоять у шапці картки.

Перевірка узгодженості даних

Головний захист прототипу це скрипт перевірки демо-даних. Емпірика проєкту проста: те, що покрито перевіркою, лишається правильним, те, що ні, розповзається. Закриваючи помилку, команда додає перевірку цілого класу таких помилок. Приклади того, що вже ловиться автоматично:

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

Чотири компанії з різними правилами

Демо містить чотири компанії: платника ПДВ на загальній системі, ФОП третьої групи без ПДВ з роздрібною торгівлею через ПРРО, нерезидента з внутрішньогруповими операціями і ще одну компанію на загальній системі для перевірки ізоляції даних. Перемикання компанії змінює дані, а не фільтрує їх. Для неплатника ПДВ функції ПДВ закриті з поясненням правової причини. Канонічна дата демо 31 липня 2026 року, і дані з пізнішою датою вважаються помилкою.

Класи автономії ШІ

Кожна дія ШІ має клас, який визначає, чи може система діяти сама:

І окреме правило для всіх класів: ШІ не стверджує факту, якого не бачив. Позначити «оригінал отримано», «години відпрацьовано» чи «документ подано» він не може незалежно від класу.

Питання замість здогадок

Коли ТЗ, демо-дані і норма права суперечать одне одному, розробник записує питання з варіантами у спільний файл і бере іншу задачу. Власник продукту відповідає пакетно. Впевнена реалізація неправильного трактування коштує дорожче за паузу.

Пілот на 30 бухгалтерах

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

Стек

TanStack Start з React 19 і Vite, файлова маршрутизація TanStack Router, Tailwind CSS 4 з компонентами shadcn і Radix, стан у памʼяті браузера, збірка сервера через Nitro для хмари або звичайного Node-сервера, Docker. Перед завершенням кожної задачі обовʼязкові перевірка типів з нулем помилок, скрипт узгодженості демо-даних і перевірка живого екрана в браузері.

Що отримує бухгалтер

• Систему, де кожен документ, проводка і звіт повʼязані і перевіряються.
• ШІ, який готує чернетки, звіряє і нагадує, але залишає рішення людині.
• Чесні статуси: видно, що зроблено насправді, а що показано в демо.
• Звичну логіку BAS: проведення, розпроведення, дії в шапці картки.

Про вибір між BAS і хмарними системами читайте у статті BAS чи хмарна бухгалтерія, а про агентів для обліку у статті AI-агенти для бухгалтерії.

Уроки

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

Автоматична перевірка важливіша за ревʼю. Людина пропускає розбіжність у сумі, скрипт її ловить щоразу.

Довіра будується з дрібниць. Одне чуже число на екрані перекреслює десятки правильних.

Як прототип стає продуктом

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

Потрібна система під ваш облік

Проєктуємо і будуємо облікові системи, кабінети і прототипи в напрямах розробка програмного забезпечення, UI/UX дизайн і розробка MVP. Інтеграцію з BAS робимо в напрямі інтеграція з BAS і 1С.

Опишіть свій облік і що в ньому забирає найбільше часу у формі заявки. Оцінку дамо після брифу за робочий день.