Multi-channel paid reports

Notes of a Numerologist: one commerce engine across web and Telegram.

A pre-launch platform for expert-led personalized products: public calculations, user accounts, payment entitlements, durable report jobs and delivery through both a website and Telegram.

Role: Independent product engineer · end-to-end owner
Status: Pre-launch · commerce and delivery hardening
Ownership: Product architecture, UX, frontend, backend, data, integrations and launch readiness

For whom: Expert-led businesses selling personalized digital reports.
The problem: Payments, access and delivery drift across website and messenger.
What I built: One backend owns the catalog, payment entitlements and durable report delivery.

The workflow behind the product.

Problem

Expert businesses often stitch together a landing page, messenger, payment links and manually produced files. Pricing, access rights, retries and customer support then drift between channels.

What I built

A personalized-content and consultation platform being prepared for launch, with one backend controlling products, money, access and generated artifacts.

Hard decisions

Prices, balances and access rights are decided by one backend rather than duplicated in the website and bot, preventing channel-specific drift.

Product surfaces16:9 · open full screen

01Website or Telegram
02Backend product catalog
03Order and payment boundary

System architecture

System map

06 connected stages

01Website or Telegram
02Backend product catalog
03Order and payment boundary
04Entitlement and wallet
05Calculation and report job
06PDF and account delivery

Current-stage evidence

Technical scope: website and Telegram, with YooKassa, shared wallet balance and Telegram Stars payment paths. Schema revision count reflects the current documented platform state.

The platform is in pre-launch. Core web, Telegram, database and worker flows are implemented; final commercial checkout, legal and operational checks remain gated before advertising starts.

Platform breadth

A complete product system, not a collection of screens.

The platform treats personalized content as a real commerce system: acquisition, identity, money, access, computation and delivery are connected through one backend instead of being duplicated across the website and Telegram.

Multi-channel acquisition

The responsive website and Telegram entry point expose one product catalog and lead customers into the same commercial workflow.

Identity and account

Phone-first authentication, the customer cabinet, orders and purchases preserve ownership across sessions and channels.

Commerce authority

Backend pricing, wallet balances and entitlements decide what was purchased and what a customer may access.

Payment orchestration

YooKassa checkout, verified webhooks, Telegram Stars and balance spending converge on idempotent fulfillment boundaries.

Generation pipeline

Versioned calculation sources and fenced workers turn paid inputs into durable report jobs without exposing retries to customers.

Delivery and operations

Artifact storage, PDF delivery, booking, administrative pricing and recovery workflows keep the business operable after purchase.

Detailed scope

Inspectable engineering decisions.

What is implemented

Public calculation modules and mobile-first product discovery
Phone-first authentication and user cabinet
Orders, purchases, wallet balance and owner-scoped access
YooKassa website checkout and verified webhook boundaries
Telegram bot, Stars and shared-balance checkout
Versioned calculation sources and backend pricing authority
Durable report workers, artifact storage and PDF delivery
Booking, admin pricing and operational recovery workflows

Hard decisions

01One authority for commerce
Prices, balances and access rights are decided by one backend rather than duplicated in the website and bot, preventing channel-specific drift.
02Idempotent payment boundaries
Provider requests, webhook handling and fulfillment are designed so retries cannot silently create duplicate value or deliver the wrong order.
03Fenced report workers
Calculation and report workers publish results only while holding the current lease, protecting completed customer artifacts from stale attempts.
04Delivery as a recorded business event
A paid product is not complete when a payment succeeds. Entitlement, generation state, artifact identity and final delivery remain traceable parts of the same order lifecycle.

Evidence

Public responsive product preview with calculation catalog
Telegram bot integrated with the same backend catalog
Versioned calculation and content truth sources
Payment, balance, entitlement and report delivery contracts
Admin-editable products, prices and booking workflows
Documented worker recovery, artifact ownership and channel parity rules

Open product preview

The decision path, step by step.

01
Choose a product on the website or in Telegram.
02
Verify payment at the backend boundary.
03
Grant the matching entitlement and run a report job.
04
Deliver the artifact through the customer channel.

This walkthrough describes the implemented scope. For an authenticated product demonstration, send a brief; no customer information is exposed here.

Discuss a similar workflow