Blog › Why Chrome extension

Why we built SocialScalr as a Chrome extension, not a cloud tool

When we started building SocialScalr we had to pick: ship it as a cloud-orchestrated tool like Expandi or HeyReach, or ship it as a browser extension like Dux-Soup or Linked Helper. Cloud is easier to build, easier to demo, and easier to sell. We picked browser-resident anyway. Here's the reasoning.

By · · 6 min read

The two architectures, one paragraph each

Cloud-orchestrated: the vendor runs a headless browser (or a proxy + scraper) on their servers. The user uploads their LinkedIn login or a cookie token. Sending invites means the vendor's servers connect to LinkedIn from the vendor's IP range and act on the user's behalf. Examples: Expandi, Lemlist's LinkedIn module, MeetAlfred, Phantombuster, Salesflow, HeyReach.

Browser-resident: the vendor ships a Chrome extension that runs inside the user's own browser session. Sending invites means the extension dispatches clicks and keystrokes inside the user's actual LinkedIn tab. The user's real IP, cookies, user agent, and device fingerprint all do the work. Examples: SocialScalr, Dux-Soup, Linked Helper, Octopus CRM, Waalaxy.

These produce identical-looking outcomes from the user's perspective. The underlying mechanics are completely different.

Why cloud is the easier business to build

We spent a week considering each. The cloud architecture wins on every short-term metric:

Every part of the operating model is easier when you control the runtime. We were tempted.

Why we picked browser-resident anyway

One reason: LinkedIn's anti-abuse machinery is specifically optimised to detect cloud automation.

This isn't a theoretical concern. It's the observable empirical pattern in the LinkedIn outreach tools category for the last 6 years:

Through all of this, browser-resident tools (Dux-Soup, Linked Helper, Waalaxy) have had a structurally better restriction profile. Their architecture isn't safe - LinkedIn flags volume regardless of source - but the architectural signal that triggers many flags ("activity from datacenter IP") just doesn't apply.

The forward-looking bet

LinkedIn's anti-abuse investments are increasing, not decreasing. Each year:

If you're starting a LinkedIn outreach product in 2026 and you build cloud, you're betting that LinkedIn's anti-abuse stops improving. That's not a bet we wanted to take.

If you build browser-resident, you're betting that real human-browser activity stays the path of least friction for LinkedIn to allow. That bet is easier to justify because LinkedIn structurally cannot block real browser activity without breaking the platform for real users.

The trade-offs we made deliberately

Choosing browser-resident wasn't free:

We can't run campaigns 24/7. The user's browser has to be open during sending hours. We solve part of this by running sends only during configured "working hours" (the default 9am-6pm local time captures most operator schedules naturally). But for agencies with truly non-technical clients who close their laptop at 5pm, this is a real constraint.

We can't pre-warm IPs for the user. Cloud tools can pre-warm a dedicated IP for 2 weeks before assigning it to a customer. We don't have this option - the customer's home/office IP is what it is. We mitigate with conservative warm-up volumes and longer ramps, but we have less control.

Chrome Web Store reviews slow our release cadence. Every extension update goes through Google's review queue, which can take 1-7 days. The dashboard ships continuously; the extension doesn't.

Manifest V3 is painful. Background service workers, restricted APIs, CSP changes. We invested heavily here and it's fine now, but the migration cost was real.

We thought all four of these were worth paying.

What we got that we didn't expect

Two upsides we didn't anticipate when we picked the architecture:

1. The LinkedIn cookie never touches our servers. A common attack vector for cloud LinkedIn tools is "vendor gets breached, attacker has cookies for thousands of LinkedIn accounts". We literally can't be breached this way because we never have the cookies. The security story writes itself.

2. The user's profile activity looks completely natural to LinkedIn. Things like profile views, "people you may know" interactions, post likes - they all happen in the real browser session in the same patterns a human would generate. Cloud tools have to fake this kind of incidental activity; we get it free.

Where we'd choose differently

If we were building for a different category, we'd probably go cloud. Email-warmup tools, social-scheduling tools, content-discovery tools - none of them face LinkedIn-style adversarial anti-abuse. The cloud architectural simplicity would win cleanly.

LinkedIn outreach is the specific category where the adversarial pressure makes cloud structurally riskier. That's why every long-running, low-restriction-rate LinkedIn tool is browser-resident, not cloud. We didn't invent this lesson; we just decided to learn from it rather than ignore it.

What this means for you

If you're evaluating tools and someone asks "is SocialScalr safe", the answer is "as safe as any LinkedIn outreach tool can be in 2026, because we picked the safer architecture upfront." If your alternative is a cloud tool with a dedicated IP, that's the second-safest tier and it's a defensible choice. If your alternative is a cheap cloud tool with rotating IPs - back away from that one, regardless of price.

Architecture matters more than any feature comparison. Pick the safe architecture first; then pick the tool that fits your workflow within that architecture.

Related reading