Cost
What rescuing an abandoned bot costs
It starts with a paid one-day audit, because nobody can fix-price a codebase they have not read. After that it is either two to five days of stabilisation or a rebuild at the normal rate. The deciding factor is almost never code quality — it is whether you control the accounts.
What rescuing an abandoned bot costs: effort, cost and what moves it
- Fixed price
- $5,880 USD
- Delivery
- Awaiting sign-off
- Effort
- 14 delivery days
- Biggest cost driver
- Data extraction from a system you no longer control
- Commercial basis
- Fixed price agreed before work starts; scope changes quoted separately
- Year one, beyond the build
- Support retainer, Managed hosting, plus credential and account recovery
As of 2025-10-01, Telegram Bot API 13.4
Why this costs what it costs
The call is always some version of the same story. The bot works, mostly. The person who built it is unreachable, or has moved on, or the agency stopped replying. Something has broken or a small change is needed, and nobody knows how to make it. Sometimes the bot has already stopped and nobody is sure exactly when, because nothing was monitoring it.
The first question is not about the code at all. It is whether you control the accounts: the BotFather account that owns the bot token, the hosting account it runs on, the domain the webhook points at, and the third-party credentials it uses. A beautifully written bot you cannot deploy is worth less than a rough one you fully control, because access can be irrecoverable while code can always be rewritten. Where a developer created the bot under their own Telegram account and cannot be reached, the honest answer is sometimes that the bot cannot be recovered and a new one must be created — with a new username, which is a real commercial loss if the old one was on your printed material.
The second question is where the data is. A bot holding six months of orders or bookings in a database inside somebody else's account is a migration problem before it is an engineering one. We start by taking a copy of everything, in a form you hold, before touching anything — because the worst outcome available in a rescue is a stabilisation attempt that loses the history.
Only then does the code matter, and the assessment is narrower than people expect. We are not judging elegance. We are asking four things: is state stored durably or in memory, are there any tests at all, does it use webhooks or long polling, and are secrets committed to the repository. Those four answers predict the cost of everything that follows better than any general impression of quality, and they can be established in a day. That day is charged, and it is the only honest way to quote what comes after it.
The breakdown
| Work | Days | Cost | What it covers |
|---|---|---|---|
| Access and account audit | 0.5 | $210 | What you control and what you do not: bot token ownership, hosting, domain, third-party credentials. Establishes whether a rescue is even possible before anything else is discussed. |
| Data extraction | 0.5 | $210 | A copy of everything the bot holds, in a form you own, taken before any change is made. The one step that is never skipped regardless of what follows. |
| Code and architecture review | 1 | $420 | State handling, test coverage, webhook or polling, secret hygiene, dependency age. Produces a written recommendation to stabilise or to rebuild, with the reasoning attached. |
| Stabilisation | 3 | $1,260 | Where the code is worth keeping: fix the immediate failure, rotate credentials, add monitoring and alerting, and document how to deploy it. Not a refactor. |
| Monitoring and runbook | 1 | $420 | The thing whose absence caused the bot to fail silently in the first place, plus written procedures so the next incident is not another rescue. |
| Rebuild | 8 | $3,360 | Where the review says rebuild: the same scope reconstructed properly, with the existing data migrated in and the same bot username retained where you control it. |
| Total | 14 | $5,880 | Fixed on signature. Scope changes are quoted separately, never absorbed silently. |
What moves the number
A bot token can only be managed from the Telegram account that created the bot.
If a departed developer created it under their own account and cannot be reached, the bot may be unrecoverable and a new username is required. Establish this on day one, because it can change the entire plan.
State held in process memory is lost on every restart.
Bots written this way appear to work and lose conversations under load or on redeploy. It is the most common single defect in inherited code and it usually means rebuilding the flow layer rather than patching it.
Long polling in production blocks horizontal scaling and hides failures.
Migrating to webhooks is a small change with a large payoff and is included in stabilisation. It is also a reliable signal that the original build followed a tutorial rather than a design.
Credentials in a repository must be treated as compromised.
Rotation is mandatory during a rescue, not optional, and it needs coordination with every third party involved. Assume the old values are known to whoever had repository access at any point.
A codebase with no tests cannot be changed with confidence.
The first change costs several times what the same change would cost in a tested system, because a characterisation test has to be written before it is safe to touch. This is what usually tips the decision toward a rebuild.
Data older than the bot's own retention behaviour may already be gone.
Some inherited bots were quietly discarding history. Extraction establishes what actually survives, and the answer occasionally changes what the business thought it had.
What year one actually costs
| Running cost | Year one | Detail |
|---|---|---|
| Support retainer | $3,480/yr | Strongly recommended after a rescue, for the obvious reason: the bot reached this state because nobody was responsible for it, and stabilisation does not change that on its own. |
| Managed hosting | $660/yr | Usually part of the rescue, because inherited bots are frequently on infrastructure nobody can log into. Moving to an account you own is often the most valuable part of the engagement. |
| Credential and account recovery | billed by the provider | Third-party account recovery is billed by those providers under their own processes and timelines, some of which are slow. This is a scheduling risk more than a cost. |
Buying the same thing elsewhere
| Where you buy it | What the money buys | What you carry |
|---|---|---|
| Find the original developer | The cheapest fix by a wide margin if they answer, because the knowledge is already in their head. Always worth one honest attempt before commissioning anything. | Availability is unknown, terms may have changed, and the same absence that created this situation tends to recur. Get access transferred to you as part of any re-engagement, whatever else happens. |
| Another freelancer, cheaply | A low quote to take it over and keep it running. Genuinely sensible for a simple bot with clean access and no data obligations. | A quote given without reading the code is a guess, and it is usually revised upward once the work starts. Ask whether they have read it, and be suspicious of a fixed price offered before they have. |
| Switch to an off-the-shelf product | A supported product with a company behind it and no inherited code at all. If your bot does something a product already does, this is frequently the right answer. | Your history and your Telegram username usually do not come with you, and the product does what it does. Worth checking against the actual flows before assuming it fits. |
Questions about the money
Why do you charge for the audit?
Because the alternative is a fixed price quoted without reading the code, which is a number that will change. The audit is a day, it produces a written recommendation you own, and you are free to take it to anybody. That seems fairer than an optimistic quote and a difficult conversation later.
Can you recover a bot if the original developer will not respond?
It depends entirely on who owns the Telegram account that created it. If that is you or someone in your company, yes. If it is the developer's personal account and they are unreachable, the token cannot be managed and a new bot is required, which means a new username. That is a genuine loss and worth trying hard to avoid.
Is it cheaper to fix or to rebuild?
Fixing is cheaper roughly two thirds of the time in our experience, and the audit says which case you are in. The reliable indicators for rebuilding are in-memory state, no tests at all, and dependencies several major versions behind — the combination, not any one alone.
Will we lose our data?
Not if we start where we always start, which is taking a copy of everything into a form you hold before touching anything. What we cannot recover is data the bot was never storing, and that is occasionally a surprise the extraction step uncovers.
Can you work with code written in a language you do not normally use?
For the audit and for stabilisation, usually yes — the patterns that matter here are language-independent. For long-term ownership we would rather rebuild on our own stack than maintain something we are slower in, and we will say so plainly rather than quietly charging more.
How quickly can a broken bot be back up?
If it is a credential or a webhook registration, often within the audit day itself. If it is architectural, stabilisation is the timeline. What we will not do is apply a fix we do not understand to get something running, because that is how a rescue becomes a second rescue.
Related reading
For how a bot reaches this state and what prevents it, read the maintenance retainer.
Where the audit recommends a rebuild, the cost is the ordinary one set out in the build breakdown.
Moving a bot onto infrastructure you actually own is costed in the hosting breakdown.
For why the original engagement ended up here, the structural argument is in the freelancer comparison.