Telegram bot with a paid subscription
The bot sells access for a period, renews it by itself and removes the people whose period has run out. Nobody reconciles the list by hand.
- Buildfrom $750
- Timeline1–3 weeks
- Supportfrom $420/mo
Who this suits: Closed channels and chats where payments arrive in no particular order, everybody’s period ends on a different day, and the reconciliation is one person’s spreadsheet.
What is in the first version
- auto-renewing subscription
- grace period
- cancel button
- reconciliation against payments
The figures above are the package this sits on: Telegram bot. Anything past its edges the calculator adds before the work starts, not after.
How the path goes
- 01
The payment opens the channel
The first charge issues a personal invite and records the date the person is inside until.
- 02
Renewals are quiet, failures are not
A failed charge starts retries and a grace period, and the person stays inside knowing the exact date it ends.
- 03
Leaving is a consequence
When the period and the grace period end, the bot removes the member and leaves a button to return.
What decides whether this works or annoys people
The channel and the list drift
Membership is reconciled against the subscription list regularly, and a discrepancy becomes a report somebody reads rather than a silent fix.
Removal is not closing the door
Invites are personal, single-use and revoked when access closes, and a return is checked against the subscription rather than a saved link.
Flickering access is worse than none
Removal happens only once the retries and the grace period are exhausted, never on the first card error.
What to measure once it is live
- renewals with no intervention
- charges recovered after an error
- gap between channel and paid list
- churn and returns to the subscription
Why this comes out faster
The shape of this one is known: the states, the edge cases and the things that usually go wrong have been decided before. Nothing here is a template, and the saving is not in your half of the work. It goes into your process, your content and the systems this has to talk to, which is the part nobody can have solved in advance.
A likely stack for this
Picked against the task when we scope it, not decided in advance. This is the shelf it usually comes off.
- Bot and accessPythonFastAPITelegram Bot APIPostgreSQL
- Charges and their scheduleStripePaddleTemporalRedis
- Screen and watching it runTypeScriptNext.jsDockerGrafana
Price it yourself, right here
Five steps, and you can see the number without leaving a contact. The estimate accounts for the kind of work, what you already have and what it will need inside.
These bills do not come from us
- provider and platform fees on charges
- the fee on a disputed charge
- hosting or a VPS for the bot
- email and SMS about charges
Asked before the first call
- How is this different from adding people by hand?
- Access is derived from the payment every day, rather than on the day somebody gets round to it. Manual additions stay available and are written into the same list rather than around it.
- Can it sell several levels of access?
- Yes: each level is its own set of channels and its own price, a move between levels reprices what is left of the period, and access is assembled from the subscription.
- How does somebody cancel?
- With a button in the bot, and an answer saying until when access runs: a cancellation you have to ask for gets disputed through a bank instead. Coming back restores the subscription.