Natalia Plankina: клиентская бизнес-система
Публичный сайт специалиста, Telegram-бот, мини-приложение, API-поверхность и контур выкладки собраны как одна бизнес-система, а не как разрозненные маркетинговые и технические фрагменты.
Этот кейс доказывает клиентскую оркестрацию: публичное доверие, путь к записи, Telegram-взаимодействие, состояние бэкенда, выкладка и восстановление рассматриваются как одна операционная поверхность.
dorodnyaya.ru
Публичный URL
сайт + бот + мини-приложение
Интерфейсы
health-точка API
Граница сервиса
> Закрытый репозиторий. Доступен для просмотра кода по запросу.
▍ Проблематика
Бизнесу специалиста нужен не отдельный лендинг. Нужен путь от первого доверия к конкретному действию, а технические части должны оставаться для клиента понятными и неразрозненными.
- Публичное доверие: Сайт должен ясно объяснять предложение, не скатываться в шаблонную медицинскую копию и держать убедительный первый экран.
- Telegram-процесс: Бот и мини-приложение должны поддерживать взаимодействие с пользователем без раздробления бизнес-состояния по разным каналам.
- Операционная передача: Понятные клиенту URL, health-точки, контейнеры и сервисы должны быть пригодны для дальнейшей поддержки.
- Восстановление: Публичная система требует повторяемой выкладки и проверок здоровья без опоры на память из чата.
▍ Архитектура
ПУБЛИЧНАЯ ПОВЕРХНОСТЬ
dorodnyaya.ru → доверие + структура услуг
↓
TELEGRAM-СЛОЙ
бот + мини-приложение → взаимодействие и путь к записи
↓
API / ДАННЫЕ
Axum-сервисы + PostgreSQL + общие типизированные контракты
↓
ЭКСПЛУАТАЦИЯ
rootless Podman | Nginx | TLS | systemd-сервисы | проверки здоровья▍ Операционные доказательства
dorodnyaya.ru
Публичный URL
сайт + бот + мини-приложение
Интерфейсы
health-точка API
Граница сервиса
rootless-контейнеры
Форма запуска
Rust workspace
Общие контракты
документированные команды
Поддержка
▍ Ключевые инженерные решения
Проблема
Публичная страница, Telegram-бот, мини-приложение и API легко превращаются в четыре несвязанных продукта.
Решение
Они собраны в одном Rust workspace с общими контрактами, явными сервисными границами и единым сценарием выкладки.
Отвергнутая альтернатива
Раздельные быстрые инструменты — проще в начале, но сложнее поддерживать, когда клиент спрашивает, что сейчас работает и что изменилось.
Проблема
Текст для пациентов легко становится либо шаблонным, либо слишком техническим.
Решение
Публичный сайт работает как поверхность доверия: конкретное описание услуг, ясная навигация и спокойная подача до того, как важна автоматизация.
▍ Технологический стек
Сайт
Rust, Leptos, SSR
Telegram
Teloxide-бот, Telegram Mini App
API
Axum, SQLx, PostgreSQL
Эксплуатация
Nginx, TLS, rootless Podman, systemd
▍ Что доказывает этот проект
Клиентские системы
Публичное позиционирование, пользовательское взаимодействие и бэкенд соединены без перекладывания технических швов на клиента.
AI-native веб-поверхность
Доверительная страница не выглядит как шаблонный генеративный сайт и ведёт к реальному первому действию.
Операционная упаковка
URL, проверки здоровья, сервисы и команды поддержки остаются обнаружимыми для повторяемого обслуживания.
Типизированная продуктовая поверхность
Общие контракты позволяют сайту, боту, мини-приложению и API развиваться как одной системе.