Vorfahr - Красивий ШІ вебзастосунок SAAS для конструктора QR сторінок

Застосунки зі штучним інтелектом - це тренд, і ми часто застосовуємо різні способи автоматизації з ШІ. У цьому проєкті об'єднано кілька сервісів AI - як для покращення старих фотографій, так і для написання тексту біографії. Також інтегровано хмарне сховище Vasaby, платіжну систему Stripe, генерацію тексту з ChatGPT, генератор і сканер QR кодів та багато іншого. Система і мобільний застосунок написані на сучасних технологіях - Angular, Python, MySQL, Docker.

Vorfahr — SaaS-платформа для QR-меморіалів, AI-контенту та внутрішнього виробничого контуру

vorfahrqr.de

Це був саме той тип проєкту, де за красивим інтерфейсом ховається не один сайт, а ціла маленька цифрова екосистема =). На поверхні користувач бачить зрозумілий сервіс із QR-кодами, сторінками пам'яті, архівом, оплатою та акуратною навігацією. Але під капотом — набагато серйозніша історія: серверна частина, адміністративна зона, ролі співробітників, виробничий облік, інтеграції із зовнішніми сервісами та AI-модулі, які реально працюють, а не просто прикрашають презентацію.

Проєкт запускався для ринку Німеччини, пізніше отримав додаткові етапи з розгортання та локалізації для України. Загалом ми закрили три великі напрями: розробку серверної частини, користувацького застосунку для десктопа й мобільних пристроїв, а також внутрішньої облікової системи для виробництва, оцифрування та руху плит. Робота була розбита на 14 етапів, і кожен із них приймався окремо. Для замовника це було важливо: прозорість, керованість, можливість спокійно перевіряти результат без стрибка в невідомість.

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

Відеоогляд однієї з пізніх версій

Нижче огляд етапу №12. Це не фінальний білд, але вже добре видно фронтенд, сценарії користувача та загальну логіку продукту.

Відгук клієнта про співпрацю

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

Ще один огляд стабільної версії

А тут — етап №10. Версія не найновіша, але вже стабільна й показова за бізнес-логікою. Добре видно, як проєкт виглядав до серії пізніх візуальних і UX-доопрацювань.

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

Що саме було зроблено

Якщо дуже стисло, ми побудували не просто лендінг і не просто застосунок, а багатошаровий SaaS-продукт. Причому продукт рідкісний за тематикою і тому особливо вимогливий до UX, довіри користувача та делікатності подачі.

• Публічна частина сервісу — лендінг, сценарії першого контакту, інформаційні сторінки та маршрут користувача до реєстрації.
• Користувацький кабінет — створення й редагування меморіальних сторінок, архів, завантаження фото, генерація біографій, робота з QR-кодами.
• AI-модулі — покращення фотографій і генерація текстів за допомогою LLM (великої мовної моделі, тобто ШІ, який уміє розуміти запит і писати текст).
• Платіжна логіка — інтеграція Stripe для оплати.
• Зовнішні входи — OAuth (безпечний вхід через сторонні акаунти) для Google і Facebook.
• Сховище даних — винесення медіа та сторінок у хмарну інфраструктуру Wasabi.
• Адміністративна зона — управління користувачами, токенами, статусами, ролями, таблицями, виробництвом, складом і залишками.
• Виробничий контур — окрема логіка для обліку, цифрової прив'язки та випуску QR-кодів.

За духом це історія на стику кількох наших напрямів одразу: AI/ML, корпоративні системи та виробничі рішення. Якщо вам цікаві близькі за архітектурною складністю проєкти, подивіться також FRACTAL, NaturalTTS і Prime EVA.

Як виглядала публічна частина сервісу

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

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

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

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

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

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

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

База питань, діалог із користувачем і сервісні сторінки

База користувацьких питань

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

Панель, де можна поставити своє питання

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

Сторінка про компанію

Розділ Про нас був зроблений не заради галочки. Для такого сервісу це важливий шар легітимності. Користувач має бачити, що перед ним не анонімна форма в інтернеті, а бренд з обличчям, естетикою та зрозумілою подачею.

QR-центр, підтримка та акаунт

QR-центр зі скануванням

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

QR-центр із вибором прив'язаного продукту

На наступному екрані видно, що система вміє не просто зчитувати код, а пов'язувати його з конкретними сутностями всередині сервісу. Це вже не декоративний QR, а робочий ідентифікатор усередині цифрової моделі продукту.

Support-центр

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

Налаштування акаунта

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

Вхід через соцмережі та за логіном

Ми реалізували панель входу з кількома варіантами авторизації: через Google, Facebook і класичну пару логін/пароль. Це OAuth-потік (коли вхід довіряється зовнішньому провайдеру, а ми безпечно отримуємо підтвердження особи), який завжди вимагає акуратної інтеграції та уваги до граничних випадків.

Реєстрація з валідацією

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

Позитивні сповіщення

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

Адміністративна зона та внутрішній контур

Ззовні сервіс виглядає естетично і легко. Усередині — вже зовсім інша музика. Там починається справжня прикладна інженерія: токени, користувачі, статуси, таблиці, виробничі сутності, склад, залишки, адміністративні дозволи та службові налаштування AI-модулів.

Саме такі розділи показують, чи був продукт справді побудований як система, чи це просто красивий фасад. У Vorfahr це була саме система. За внутрішньою організацією проєкт місцями ближчий до корпоративних рішень на кшталт platFORMA і FORMA WMS, ніж до звичайного маркетингового сайту.

Ролі в системі теж були розділені не для краси. Менеджер складу, виробник, продавець, магазин, адміністратор — у кожного свій контур дій і свій рівень доступу. Це вже RBAC-модель (role-based access control, тобто права будуються навколо ролей, а не хаотично роздаються вручну).

Архів, QR-профілі та конструктор сторінок

Архів сторінок

Розділ архіву — одна з центральних користувацьких зон. Тут людина працює не з абстрактною системою, а зі своїми матеріалами, профілями та пов’язаними сторінками. Це важливий перехід від ідеї сервісу до реальної повсякденної користі.

Вибір QR-кодів і пов’язаних профілів

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

Завантаження QR у різних форматах

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

WYSIWYG-конструктор сторінок

Далі починається один із найцікавіших модулів — візуальний редактор сторінки. Це WYSIWYG-підхід (what you see is what you get, тобто редагуєш і одразу бачиш майже фінальний результат). За відчуттями він ближчий до Tilda або Wix, але заточений під конкретну предметну область і інтегрований із логікою сервісу.

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

Завантаження фотографій

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

Слайдер фотографій

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

AI-покращення фотографій

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

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

Інші способи введення даних

Конструктор не обмежувався одним форматом взаємодії. Ми передбачили й інші способи введення даних, щоб користувач міг зібрати сторінку тим способом, який йому ближчий, а не тим, який зручніший розробнику.

Генерація біографії через LLM

Окремий сильний модуль — написання біографії за допомогою LLM. На момент розробки використовувалася модель OpenAI GPT. Причому текст з’являвся не сухим блоком наприкінці запиту, а інтерактивно, по літерах, з анімацією живого набору. Такий ефект робить взаємодію не лише технологічною, а й емоційно зрозумілою.

Результат генерації сторінки

Нижче — результат роботи конструктора. Саме заради такої зв’язки й будувалася вся логіка: зручний редактор, зрозуміле введення даних, AI-допомога й акуратний вихід у готову сторінку, яку не соромно показати людям.

Сімейний архів і доступний простір

Система сімейного архіву відображає доступний простір, дає вибрати вже створену біографію або створити нову, а також пов’язує сторінки з конкретними QR-кодами. Це вже не просто набір карток, а структуроване цифрове сховище з логікою зв’язків.

Налаштування доступу до сторінки

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

Відновлення пароля

Відновлення пароля теж зроблено акуратно й по-дорослому. Зазвичай це той розділ, який усі вважають нудним, доки він не ламається. Ми воліємо, щоб не ламався =).

Дизайнерські сповіщення

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

Захищена генерація QR-кодів

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

З якими складнощами ми зіткнулися

1. Python, Django і не найпростіший серверний стек

Замовник був технічно грамотним і добре розумів, чого хоче. Зокрема, він наполягав на Python-стеку: перша версія проєкту вже писалася на Python, і було бажання продовжити саме в цьому напрямі. Серверна частина в підсумку будувалася на Django, а хостингова історія була зав’язана на Python Anywhere.

Скажімо акуратно: Python — чудова мова для роботи з даними, математикою, автоматизацією та AI. Але в класичній веброзробці екосистема PHP-фреймворків на кшталт Laravel, Symfony або навіть старого доброго Yii2 історично багатша на типові рішення, пакети та звичні інструменти. Тому ми пішли назустріч там, де це було розумно, але в критичних місцях наполягли на більш стійкій архітектурі — наприклад, зробили фронтенд окремим застосунком і пов’язали його із сервером через API (набір дверей, через які дві програми розмовляють одна з одною).

2. Часті зміни дизайну та каскадний вплив на логіку

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

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

3. Велика кількість зовнішніх інтеграцій

У проєкті було одразу кілька зовнішніх контурів: AI-сервіси, хмарне сховище, Stripe, OAuth, Google, Facebook та інші залежності. На папері це виглядає як список логотипів. На практиці — це постійна робота з документацією, розбіжностями реальної поведінки API, реєстраціями, підтвердженнями, доступами, кабінетами партнерів і дивними граничними кейсами, які ніхто не любить, але всі чомусь отримують.

Особливо весело буває там, де зовнішній сервіс живе за своїми внутрішніми законами й не надто прагне зробити життя інтеграторів легким. Але в підсумку вся зв’язка була зібрана й працювала стабільно.

4. Відсутність наддетального ТЗ на старті

Ми не працювали наосліп. На старті були вимоги клієнта, уточнення, продумані модулі, функції, компоненти й детальний дизайн під десктоп, планшети та мобільні пристрої. Однак часу саме на системний аналіз (розбір бізнес-процесів і точну формалізацію сутностей) було приділено менше, ніж ми зазвичай рекомендуємо.

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

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

Використані технології

• Фронтенд: Angular, TypeScript, HTML, CSS.
• Бекенд: Python, Django, MySQL.
• Інфраструктура: Linux, BASH, Docker, Docker Compose.
• Хмарне зберігання: Wasabi.
• Інтеграції: Stripe, OAuth, AI-сервіси, Google, Facebook.

Якщо вам близькі проєкти, де потрібно не просто зверстати інтерфейс, а спроєктувати архітектуру, ролі, процеси, інтеграції та масштабовану внутрішню модель, зверніть увагу також на кейси Prime EVA, platFORMA і FORMA WMS.

Підсумки проєкту та користь для замовника

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

Що отримав замовник:

• Рідкісний і помітний продукт, який справді вирізняється на ринку Німеччини.
• Масштабовану систему, готову до подальших доопрацювань і локалізації на нові ринки.
• Сильну AI-складову, вбудовану в реальні користувацькі сценарії.
• Прозорий процес розробки з поетапною здачею, контролем якості та зрозумілою логікою розвитку.
• Поєднання публічного інтерфейсу та внутрішнього контуру, що особливо важливо для продуктів, де онлайн-сервіс пов’язаний із реальними операціями та виробництвом.

Чому кероване розтягування строків тут було плюсом

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

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

Потрібен схожий проєкт?

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

А якщо хочете спочатку подивитися ще кілька суміжних кейсів перед розмовою — це теж правильний шлях =). Для продовження читання добре підходять FRACTAL, NaturalTTS, Prime EVA і platFORMA.