Bodywork website and booking system

A website, Telegram bot, mini app, and API carry one visitor from understanding the specialist's work to booking without repeating the request.

Open Project ↗

Visitor path

A visitor understands the specialist's work on the public page, continues in Telegram, and reaches booking without starting the request again.

Shared request state

The website, bot, mini app, and API use the same data instead of turning one inquiry into several disconnected records.

What the owner can recheck

The owner can identify what is live and recheck the complete path after a change or restart.

The project job

The public page explains the specialist's work, Telegram continues the same inquiry, and the booking step receives the context already supplied by the visitor.

What must work as one path

A clear first contact: The website explains the specialist's work in concrete language and gives the visitor a clear next step.
Booking without a reset: The bot and mini app continue the same client path instead of asking the visitor to reconstruct the request.
One working version: The owner can tell which site, bot, and API version is live and whether the complete path works.
Repeatable recovery: The system can be started and checked again without reconstructing the procedure from old chat messages.

One path across the system

PUBLIC WEBSITE
  dorodnyaya.ru → specialist context + next action
          ↓
TELEGRAM
  bot + mini app → questions + booking path
          ↓
API + DATA
  one request state across every interface
          ↓
LIVE SYSTEM
  version identity | health checks | recoverable services

What the complete path shows

dorodnyaya.ru

Public Site

site + bot + mini app

Entry Points

first contact to booking

Client Path

shared across interfaces

Request State

identified and checked

Live Version

repeatable start and recovery

Support

Why the parts stay together

Problem

A public page, Telegram bot, mini app, and API can easily drift into four unrelated products.

Solution

Keep them in one Rust codebase with shared data contracts and one repeatable way to start and verify the complete path.

Why not that option

Building each channel separately is faster at first, but then the request state, service wording, and live version have to be reconciled by hand.

Why the public wording is shared

Problem

If the website and Telegram flow describe the specialist's work differently, booking starts with clarification instead of continuing the same request.

Solution

The website, bot, and booking path use the same service terms, non-medical scope, and next-step expectations.

Implementation

Site

Rust, Leptos, SSR

Teloxide bot, Telegram Mini App

API

Axum, SQLx, PostgreSQL

Operations

Nginx, TLS, rootless Podman, systemd