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.