Natalia Plankina: Client-Facing Business System
A public specialist website, Telegram bot, mini app, API surface, and deployment contour assembled as one business system instead of separate marketing and automation fragments.
This case proves client-facing orchestration: public trust, appointment flow, Telegram interaction, backend state, deployment, and recovery are treated as one operating surface.
dorodnyaya.ru
Public URL
site + bot + mini app
Interfaces
api health endpoint
Service Boundary
> Private repository. Available for code review on request.
▍ Problem Space
A specialist business does not need a landing page in isolation. It needs a path from first trust to a concrete next action, with the technical parts staying invisible to the client.
- Public Trust: The website must explain the offer clearly, avoid generic medical copy, and keep the first screen credible.
- Telegram Workflow: The bot and mini app need to support user interaction without splitting the business state into disconnected channels.
- Operational Handoff: Client-recognizable URLs, health endpoints, containers, and service units must be understandable for future support.
- Recovery: A public system needs deployment and health checks that can be repeated without relying on chat memory.
▍ Architecture
PUBLIC SURFACE
dorodnyaya.ru website → trust + service structure
↓
TELEGRAM LAYER
user bot + mini app → interaction and appointment path
↓
API / DATA
Axum services + PostgreSQL + typed shared contracts
↓
OPERATIONS
rootless Podman | Nginx | TLS | systemd units | health checks▍ Operating Proof
dorodnyaya.ru
Public URL
site + bot + mini app
Interfaces
api health endpoint
Service Boundary
rootless containers
Runtime Shape
Rust workspace
Shared Contracts
documented commands
Support Surface
▍ Key Engineering Decisions
Problem
A public page, Telegram bot, mini app, and API can easily drift into four unrelated products.
Solution
Keep them in one Rust workspace with shared contracts, explicit service boundaries, and one deployment runbook.
Alternative Rejected
Separate quick tools — easier at first, but harder to support when the client asks what is live and what changed.
Problem
Patient-facing copy can become either too generic or too technical.
Solution
Use the public site as a trust surface: concrete service framing, clear navigation, and restrained presentation before any automation layer matters.
▍ Tech Stack
Site
Rust, Leptos, SSR
Telegram
Teloxide bot, Telegram Mini App
API
Axum, SQLx, PostgreSQL
Operations
Nginx, TLS, rootless Podman, systemd
▍ What This Proves
Client-Facing Systems
Connecting public positioning, user interaction, and backend operation without making the client manage the technical seams.
AI-Native Web Surfaces
Building credibility surfaces that avoid generic generated presentation and support a real first user action.
Operational Packaging
Keeping URLs, health checks, service units, and support commands discoverable for repeatable maintenance.
Typed Product Surface
Using shared contracts so the website, bot, mini app, and API can evolve as one system.