A Telegram Mini App CRM for Podology Center: center-wide control for admins and a private earnings workspace for every podologist.
Switch between Admin and Worker, choose a page and change the month. Login is shown separately. Numbers and people below are sample data for the design only.
Обзор денег, процедур и команды
Сравнение нагрузки и результата
Поиск по имени, телефону, мастеру или дате
Из чего складывается выручка центра
Личный результат · только ваши данные
Другие мастера и их клиенты недоступны
Прозрачный расчёт по каждой процедуре
Доступ и настройки
Role filtering is enforced by the backend on every request. Hiding a menu item in the frontend is helpful UX, but it is never treated as security.
| Capability | Admin | Worker | First release? |
|---|---|---|---|
| Center dashboard and total revenue | Yes | No | Yes |
| All workers and worker comparison | Yes | No | Yes |
| All clients and appointment search | Yes | No | Yes |
| Own clients, visits and procedures | Yes | Own only | Yes |
| Own salary from first day of selected month | All workers | Own only | Yes |
| Procedure and payment analytics | Center-wide | Own only | Yes |
| Edit appointment, money or business data | Confirmed writes | Confirmed own scope | Later iteration |
| Inventory, PDFs and advanced exports | Yes | Own reports | Later iteration |
The Mini App gets a dedicated frontend and a new CRM API boundary. Existing Podology business tables remain the source of truth; calculations and access rules live server-side.
Admin or approved worker launches the Mini App from the current bot.
Mobile TypeScript UI, Telegram themes, safe areas, role-specific navigation.
Validate Telegram init data, then phone + password; issue short-lived session; enforce Admin/Worker scope.
Class-based controllers, services, repositories, DTOs and audit policy.
Parameterized queries, pagination, read models, transactions for future writes.
Current appointments/workers stay authoritative. New sessions, audit and salary snapshots use separate migrations only after approval.
No DB credentials, bot token, salary rules or passwords in browser code. Telegram display data is not trusted without backend validation.
The Mini App is opened by the existing bot. We do not create a second poller for the same Telegram token.
Initial CRM endpoints only read and calculate. Write operations come later with explicit confirmation and audit history.
User opens CRM from the bot menu/button.
Backend validates raw launch data and freshness.
Phone + existing password identify worker/admin.
Server creates a scoped session and role context.
Repositories apply worker ownership filters before data leaves the server.
Require phone + password on the first link, on a new Telegram account/device, and after an expired/revoked session. For normal returns, validated Telegram launch data can resume a short-lived secure server session. The final policy should be confirmed before implementation.
We will not create one large procedural file. UI screens, auth, calculations and persistence are represented by classes with narrow responsibilities and test seams.
src/
app/
TelegramBridge.ts
AppRouter.ts
SessionStore.ts
ApiClient.ts
auth/
AuthSession.ts
LoginPage.ts
RoleGuard.ts
admin/
AdminDashboardPage.ts
WorkersPage.ts
AllClientsPage.ts
ProcedureReportPage.ts
worker/
WorkerDashboardPage.ts
MyClientsPage.ts
MyEarningsPage.ts
components/
MonthSelector.ts
MoneyCard.ts
ClientList.ts
ProcedureTable.tsapp/
controllers/
AuthController.py
WorkerController.py
AdminController.py
services/
AuthService.py
RolePolicy.py
WorkerDashboardService.py
AdminAnalyticsService.py
SalaryCalculationService.py
repositories/
WorkerRepository.py
ClientRepository.py
ProcedureRepository.py
SessionRepository.py
domain/
User.py
Role.py
Money.py
SalaryPeriod.py
infrastructure/
MariaDbUnitOfWork.py
TelegramInitDataValidator.py
tests/
unit/ integration/ authorization/TypeScript + Vite with class-based page/components. Small payload, direct Telegram WebView integration, OOP-friendly.
Python FastAPI for transport, with thin class-based controllers and all rules in domain/services/repositories.
MariaDB remains the source. Use indexed read queries, DTOs and separate migrations for any new CRM-only tables.
Each phase lives in its own feature branch and pull request. You review the real behavior, approve or request changes, and only then we merge and start the next phase.
Freeze exact salary, role and monthly-period rules.
Scaffold frontend, backend, CI and local environment.
Telegram launch verification plus existing phone/password login.
Own earnings from day one of a selected month.
Own client list, search and visit history.
All workers, clients, earnings and procedure mix.
Monthly drilldowns and export/PDF options.
Only after read-only CRM is trusted.
Production quality, privacy and Telegram WebView testing.
Feature branch → tests and preview → pull request → your review → changes if needed → your approval → merge.
Acceptance criteria demonstrated, tests passing, role boundaries verified and no unresolved privacy/security issue.
A new private Git repository is recommended because this CRM has a separate frontend, API contract, migrations and release lifecycle.
Please create the private Git repository when this concept direction is approved. Then provide the repository URL and preferred default branch protection rules. No production database, bot routing or deployment should change during the initial scaffold.