Telegram Growth Agency vs In-House: The Real Cost Model

Someone quoted you a number to grow your Telegram group and it felt high. The obvious response is to bring it in-house - the tooling is open source, the scripts are on GitHub, how expensive can phone numbers be.

The honest answer is that in-house is genuinely cheaper per unit at steady state, and that most people who try it never reach steady state. Both halves of that sentence matter. Here is the full cost model, including the four line items that comparison posts written by agencies always leave out.

The line items nobody prices

Telegram-capable phone numbers. Not all virtual numbers can receive a Telegram OTP. SMS activation services price Telegram specifically higher than generic SMS because the success rate is lower and the numbers burn faster. Budget somewhere in the range of $0.50 to $3 per successful registration depending on country, and assume a meaningful failure rate on top - you pay for attempts that never deliver a code. Cheap-country numbers cost less and get restricted sooner, which is not a coincidence.

Mobile or residential proxies. Datacenter IPs get accounts restricted fast enough that they are a false economy. Shared mobile proxy ports run a few dollars per port per month; residential is usually metered per gigabyte. You cannot put forty accounts behind one IP - the association is exactly what anti-abuse systems look for. Plan roughly one port per two or three accounts.

Warming time. A freshly registered account that immediately starts adding people to a group gets limited within hours. Accounts need age and some ordinary-looking activity before they can do useful work - a week or two of sitting, joining a few public groups, sending occasional messages. During that period the account costs money and produces nothing. This is the line item that makes month one so much worse than month three.

Ban replacement. Accounts hit PEER_FLOOD, then a spam restriction, then in many cases a permanent limitation. Some can be appealed through Telegram's spam bot; many cannot. Under sustained adding load, plan on a median useful lifespan measured in days, not months. Every dead account means a new number, a new warming cycle, and a new proxy slot.

Human hours. This is the largest cost in every honest version of this model and the one people zero out because it is their own time. Someone has to monitor flood-wait errors, rotate dead accounts, re-run failed batches, and watch that the group itself does not get reported. Ten to twenty hours a week during setup, less once it runs, never zero.

Throughput: the constraint that sets everything else

The whole model hangs off one number: successful adds per account per day.

A warmed account operating conservatively manages something in the region of 20-40 successful adds per day. Push harder and you trade a few days of extra output for the account's entire remaining lifespan. Note that successful is doing work in that sentence - a large share of your add attempts fail before they count, because the target has restricted who can add them to groups, or is not a mutual contact, and failed attempts still consume your rate budget and still push the account toward a restriction.

So if an account manages 30 successful adds a day and survives nine days under load, its lifetime output is around 270 members. To deliver 10,000 members you need roughly 37 accounts consumed, plus a warming pipeline running behind them so you are never waiting on registration. Call it 45 accounts provisioned across the month.

That is the number that makes the rest of the arithmetic possible.

Full in-house cost, 10,000 members a month

Line item	Basis	Monthly
Phone numbers	45 needed, 25% OTP failure → 60 purchases at ~$1.50	$90
Mobile proxy ports	18 ports at ~$4	$72
VPS	Single small instance running the workers	$40
Tooling	Off-the-shelf panel, or amortised dev time on Telethon	$80
Operator hours	15 hrs/week × 4 weeks at $15/hr	$900
Total		$1,182
Cost per 1,000		$118

Now zero out the labour line, because that is what actually happens when a founder does it themselves:

Scenario	Monthly cost	Cost per 1,000
10,000/mo, labour at $15/hr	$1,182	$118
10,000/mo, founder's own time unpaid	$282	$28
3,000/mo, founder's own time unpaid	$169	$56
3,000/mo, labour at $15/hr (40 hrs)	$769	$256
25,000/mo, labour at $15/hr (80 hrs)	$1,725	$69

Two crossovers fall out of this, and they are the whole decision.

With unpaid founder time, in-house beats a $60 flat rate above roughly 3,000 members a month. That is a low bar and it is true. If you are going to run this yourself, indefinitely, at volume, you will spend less per member than you would buying it.

With any paid labour at $15/hr, in-house does not beat $60 per 1,000 until you are somewhere north of 40,000 members a month, because the labour line barely shrinks as volume grows - a bigger account fleet needs more babysitting, not less. At $25/hr, which is what a competent operator who will not get your group banned actually costs, the crossover moves out far enough that most operators never reach it.

What month one really looks like

The tables above describe a running system. Getting there is a separate cost, and it is where the majority of in-house attempts die.

Weeks one and two go to registration and warming. You are buying numbers, configuring proxies, and running accounts that do nothing. Output: near zero. Spend: most of the fixed costs plus the heaviest labour week you will have.

Week three is when you discover your throughput assumptions were optimistic. First PEER_FLOOD wave, first batch of permanently limited accounts, first realisation that your add-success rate is 45% and not the 90% you modelled.

Week four produces real members. Maybe 3,000-4,000 against a 10,000 target.

So month one costs roughly a full month of the model and delivers 35-40% of it. At paid labour that is $1,182 for 3,500 members - $338 per 1,000. Month two is better. Month three is the number in the table. Whether you get to month three depends entirely on whether you are still interested by then.

The risk line item

One cost has no dollar figure and belongs in the decision anyway: your group. Aggressive adding gets groups reported. A reported group can be restricted, and a restricted public group loses its search visibility, which is often the actual asset. Doing this in-house means your production group is the test environment.

Agencies carry that risk on account fleets that are not yours, which is a real part of what the margin buys. It is also why pace caps matter more than they sound: 10,000 members arriving in 24 hours is a different risk profile from 10,000 arriving over three weeks, at identical cost.

For context on where a flat rate sits in this model - and this is our own pricing, so discount it as you see fit - TeleReach fills a Telegram group from source groups you name or from a US online-shopper pool at $60 per 1,000, stepping down to $52 at 50,000, with no setup period and no account fleet on your side of the ledger. Against the tables above, that is worse than a founder running it themselves at volume and better than almost any version with paid labour in it. Which is the honest way to frame the choice: this is a build-versus-buy decision about your time, not about the tooling.

What usually goes wrong in-house

Datacenter proxies. They are a tenth the price and they get accounts restricted at multiples of the rate. This is the single most common reason a first attempt fails inside two weeks.

No warming pipeline. Running one cohort of accounts until they die, then starting registration from scratch, means output arrives in waves with two-week gaps. Register continuously so there is always a warmed cohort behind the working one.

Modelling attempts as adds. Privacy settings block a large fraction of add attempts outright. If your plan assumed every enumerated member is reachable, your account count is short by roughly half.

Delivering in a spike. The fastest way to get both the accounts and the destination group actioned. Spread it, cap daily pace, and vary the timing.

Counting founder time at zero and then quitting. The unpaid-labour column is only real if you keep doing it. Half the people who use that column to justify in-house have abandoned the system by week five, having paid all the setup costs and captured none of the steady-state savings.

Which one you should pick

Run it in-house if all three are true: you need more than about 5,000 members a month, on an ongoing basis, and the person doing the work costs you nothing or is already on payroll for adjacent work. That combination genuinely wins on cost, and you end up owning infrastructure you can point at any group you launch afterwards.

Buy it if any of those fail. One-off builds, spiky demand, or a team where the person who would run this is your only engineer - in every one of those cases the setup cost never amortises and you are paying month-one economics forever.

Next step

Take your actual target for the next 90 days and put it into the table above with your own hourly rate in the labour line. If in-house comes out ahead, buy ten numbers this week and try to warm them - the exercise costs about $15 and tells you more about whether you will really do this than any spreadsheet will.

If it comes out behind, price the volume directly and spend the reclaimed 60 hours a month on the part of the business that has no supplier.