Telegraft

Services

The catalogue, with the disqualifiers left in

Twenty-four Telegram bot types, split between GCC operations automation and crypto and Web3 product work, plus a retrieval-backed AI assistant tier. Each page carries an exact price, an exact delivery time, the real Telegram limits involved, and a section on when not to build it.

Telegram bot types: what this section covers

Catalogue size
24 bot types, each with an exact price and an exact delivery window
Verticals covered
Crypto and Web3, and GCC operations. Work outside those two is turned down
Pricing form
One exact figure per type — never a range, never "starting from"
Source ownership
The client owns the source at handover

As of 2025-10-01, Telegram Bot API 13.4

Why the catalogue is shaped like this

Most agency service pages are a list of capabilities with no prices and no disqualifiers, which makes them impossible to compare and impossible to disagree with. This catalogue is the opposite. Each page names a figure, names a number of days, and includes a section arguing against the build for the cases where it is the wrong answer. That last section is the one worth reading first.

The split into two verticals is deliberate and is the main reason the pages contain anything useful. A booking bot for a Dubai clinic and a token launch bot for a project in Zug share almost nothing beyond the API: different buyers, different failure modes, different regulators, different definitions of done. Studios that build anything for anyone produce pages that could describe any of it, which is exactly the templated prose this catalogue is written to avoid.

Prices are fixed rather than estimated, and that constrains what can be sold. A fixed price only works where the scope is genuinely knowable in advance, which is why the catalogue is a set of defined products rather than an open-ended engineering offer. Where a requirement does not fit one of these shapes, it is quoted separately rather than forced into a shape it does not fit.

GCC operations automation

Clinics, restaurants, brokerages, logistics, rental and professional services across the UAE, Qatar, Saudi Arabia and the wider Gulf. Telegram is chosen here because staff and a large share of customers are already in it, and because a bot costs nothing per message where a messaging API charges per conversation.

Crypto, Web3 and TON

Exchanges, launchpads, token projects and DAOs where Telegram is the product surface rather than a marketing channel. These builds are priced higher because a defect is a production incident rather than a missed booking, and because a third of the work is failure handling that never appears in a demo.

AI assistants

The premium tier: assistants that retrieve from your own documents and cite what they used, or decline. Sold into both verticals, and the tier where the engineering effort concentrates on refusal behaviour rather than on generation.

Questions about how this is sold

Why are the prices exact rather than a range?

Because a range is not a price, it is a negotiating position. Fixed pricing only works where scope is genuinely knowable in advance, which is why this is a catalogue of defined products rather than an open engineering offer. Requirements that do not fit one of these shapes are quoted separately.

What happens if the scope turns out to be larger than the fixed price assumed?

That risk sits with us, which is the point of quoting a fixed price. Where a discovery genuinely changes the product rather than its difficulty, it is discussed as a change of scope rather than absorbed silently or invoiced as a surprise.

Do you build things outside this catalogue?

Sometimes, and always at a different price basis, because the fixed figure depends on having built the pattern before. The two verticals exist because the second time you build something is when it gets good, and a studio that builds anything for anyone never gets a second time.

Why does every page include reasons not to buy?

Because they are the fastest way for a buyer to disqualify themselves before either side spends time, and because a page that only argues one way carries no information. Several of these pages will talk a reader out of the build, which is the intended outcome when the build is wrong for them.

Which of these can be combined?

Most of them, and several are commonly built together — ordering with delivery tracking, booking with review collection, a wallet with KYC. Combined builds are scoped as one project rather than summed from list prices, because the overlap is substantial.

Do we own the code?

Yes, outright, including the repository and the deployment configuration. It matters more than it sounds: a studio that retains the code retains the relationship, and the terms should say plainly which arrangement you are in.

Related reading