The scaling mistake looks like this: a batch is bought, loaded in one evening and put on a task the same evening. A week later it is not one account that drops out but the whole batch.
Why as a group
Because every account in the batch shares a history: one seller, one first login date, one configuration method, often adjacent addresses. Whatever kills one kills the rest, simply because they are identical.
An order that spreads the risk
One: loading the whole batch is fine, putting it to work is not. Release a few per day.
Two: attach each account its own proxy before the first connection, not after — why, in checking in the first hour.
Three: a trial batch before a large one. Three accounts and a week of work tell you whether fifty from this seller are worth it.
What to verify before loading
Completeness: every .session needs its own .json. Formats are in account formats. A batch where half the files have no pair will configure wrongly, and you will find out on day three.
Records
Start the table before loading, not after: seller, date, geo, proxy, date entered service. Without it you cannot tell a month later which batch drops out faster — see how long an account lives.
How Neurogram handles it
Upload takes files in bulk, each account gets its own proxy, and gradual release is described in the guide. The load ramp itself is in the warm-up calculator.
Buy accountsaged, with full session files