Case Study: How We Built instaoutreach, an Anti-Ban Instagram Outreach Engine

Cold outreach on Instagram has one hard problem that everything else is downstream of: the platform bans automation aggressively. Most tools ignore this, blast identical DMs from a fresh account on a raw datacenter IP, and get shadowbanned within a day. So when we built instaoutreach, a multi-tenant engine for running cold outreach across many Instagram accounts, we did not start with the messaging. We started with not getting banned, and let that decision shape every layer above it.

This is not a story about a reply rate; it is a story about how the engine is built and why we built it the way we did. The short version: anti-ban is not a setting in instaoutreach, it is the architecture.

The problem we set out to solve

The problem was never sending messages. It was sending them at scale, from many accounts, without the platform shutting them down.

So the brief was unusual: assume the platform is actively trying to detect and ban you, and build a system that behaves so much like real people that it does not trip those defences, while still doing real work at scale.

One pipeline: how outreach flows

Every prospect moves through the same careful sequence, and the order is the point. The system does not DM a stranger out of nowhere; it discovers the right targets, warms the sending account, engages with the prospect first, and only then sends a personalized message, with a human supervising the replies that matter.

Anti-ban is the architecture

The single rule that everything else follows is identity isolation: one account is bound to one sticky residential proxy and one frozen device fingerprint, for its entire life. Sessions are persisted and reused instead of logging in fresh each run, because repeated logins are themselves a red flag. Actions on a single account run strictly one at a time, never in parallel, with randomized delays and active windows that match real business hours in the account's own timezone. New accounts are gated through a warmup period before they are allowed to send a single DM, and even then daily caps start low and rise slowly. Locale, country and timezone are pinned to match the proxy's geography, so nothing about the account contradicts anything else. None of this is glamorous, and all of it is what keeps the accounts alive.

Warm before you ask

The other half of staying safe is behaving like a person who is actually interested, not a machine that wants something. Before any DM, the engine engages: it likes and comments on the prospect's content, so the first message arrives from an account the prospect has already seen, not a cold stranger. Discovery feeds this with the right people in the first place, finding prospects by hashtag, by a competitor's followers, by a seed list, or by location, so the accounts are always engaging with a relevant audience rather than random profiles.

Messages that sound human, replies a human approves

When a DM does go out, it is personalized by AI so no two messages are identical, which both performs better and avoids the identical-text pattern platforms flag. For the moments that matter, the system can send a short clip in the operator's own recorded voice rather than synthetic text-to-speech, because a real voice note converts and reassures in a way text cannot. Replies are deliberately human-in-the-loop: cold and early threads are drafted by an AI setter for a person to approve, and only warm, qualified conversations move faster, always at a human pace. Fully automatic replies are exactly the kind of behaviour that gets accounts banned, so we refused to build them.

Under the hood

instaoutreach is a custom application, not a browser macro on a single machine.

• A multi-tenant engine on Postgres with row-level security from day one, so many orgs and dozens of accounts stay strictly isolated, with an API, a background worker and a scheduler (Celery + Redis).
• One proxy and one frozen device fingerprint per account, for life, with sessions persisted and reused rather than re-created, because consistency is what looks human.
• A serial, randomized action queue per account, with warmup gating, slowly rising daily caps, and business-hours windows pinned to the proxy's timezone.
• A discovery engine that sources prospects by hashtag, competitor followers, seed lists or location, so accounts always engage a relevant audience.
• An engagement-first flow, liking and commenting before any DM, so outreach arrives warm.
• AI-personalized messages and real recorded voice clips, never identical text, never synthetic speech.
• A human-in-the-loop AI setter that drafts replies for approval and books calls through Cal.com, with encrypted storage for every credential and session.

Why weeks, not quarters

A system this careful usually sounds like a long project. It is not, because the build follows the same process we use on every project: a tight scope, an agent-assisted build, and a deployment that is monitored from day one. We break the method down in how we ship custom apps in weeks, and the build-versus-buy logic in build vs buy: when a custom app wins.

What we would tell anyone considering this

A few honest lessons from the build.

• Design for the platform's defences, not against them. The accounts that survive are the ones that behave like people. Safety could not be a feature bolted on at the end; it had to be the foundation.
• Warm beats clever. Engaging with a prospect before messaging them does more for outcomes than any subject-line trick, because the first DM is no longer cold.
• Keep a human on the replies. Full auto-reply is the fastest way to lose an account. The setter drafts; a person decides.

If you want to run outreach at scale without burning accounts, talk to us. We will look at how your outreach runs today and show you what a safety-first engine would change before we build anything.