Building LinkedIn integration in-house — should you?
The honest answer: usually no, but not always. Here’s the math, the timeline, and the signals that tip the decision either way. We’re a vendor, so we tried to make this fair.
Year-one TCO · sample workload
50k profiles/mo · 200 identities · 1 eng| Line item | Build | Buy |
|---|---|---|
| Engineer build (6 weeks) | $36,000 | — |
| Engineer maintain (15 h/mo) | $21,600 | $1,440 |
| Proxies + residential IPs | $4,800 | — |
| LinkedIn accounts + warmup | $2,880 | — |
| API spend | — | $32,370 |
| Outage cost (~2/yr) | $8,000 | $0 |
build · year 1
$73,280
buy · year 1
$33,810
$39,470 saved · 54%
// The two paths
Same job, two stacks. Different time-to-prod, different on-call profile.
Both can get the same data out. What changes is where the engineering effort sits and who's on the hook when LinkedIn ships a UI change.
Option A · build
Build in-house
Your engineers own selectors, sessions, anti-bot posture, and a parsing layer per LinkedIn surface.
Full control over data shape and freshness policy.
No vendor risk — your dependency surface is yours.
Per-call cost trends to zero once volume is huge.
6+ weeks from kickoff to a production-grade enrichment endpoint.
15+ engineering hours / month on selector maintenance and incident response.
You own ToS posture — a misconfigured scraper kills accounts.
Adding the next surface (signals, Sales Nav, engagement) starts the cycle over.
Option B · buy
Use Edges
Call documented endpoints. We own selectors, sessions, anti-bot posture, and the parsing layer per surface.
2 days to first call — sign up, get an API key, drop in the SDK.
~1 hour / month of engineering time on LinkedIn integration.
70+ actions behind one key — adding signals or Sales Nav is one new call.
SLA + status page. When LinkedIn breaks, we tell you.
SOC 2 Type II on day one — your buyers' security review passes.
Per-call cost — a real line item, even with the engineering savings.
Vendor dependency. If we sunset an action, you migrate.
// Realistic timeline
From kickoff to "shipped to a customer".
Estimated from interviews with 12 teams who built LinkedIn integration in-house, then switched to Edges. Your mileage varies; the shape doesn't.
Build · 8 weeks before production
- Week 1
Spike: HTML parsing
Pick a target page, write the first selector pass, see what breaks. Decide on Cheerio vs Playwright vs headless Chrome.
- Week 2–3
Session pool + proxies
Buy proxies. Wire up cookie storage. First account suspension teaches you about LinkedIn fingerprinting.
- Week 4–5
Rate posture + retries
Add jitter, backoff, per-account budgets. Build the retry queue. Tune until LinkedIn stops flagging the accounts.
- Week 6
Hit the long tail
The 14 edge cases — private profiles, premium-only fields, geo-routed surfaces, recently-renamed companies.
- Week 7–8
Productionize
Logging, alerting, status page, runbook. Postmortem the first selector breakage at 2 a.m. Ship to customers.
Buy · 2 days before production
- Day 1 · AM
Sign up & key
Get an API key.
npm i @edgesrun/sdk. Read the quickstart. First successful call tolinkedin-extract-peoplein 30 minutes. - Day 1 · PM
Wire into product
Drop the SDK into your backend service. Map your CRM trigger to the enrichment call. End-to-end in staging by EOD.
- Day 2
Ship to a customer
Run a 50-record dual-run if you're cautious. Flip the feature flag. Done.
- Ongoing
~1 h / month
Review the changelog when we ship new actions. That's the maintenance budget.
// When to switch
Signals it's time to stop building and start calling.
If three or more of these are true for your team this quarter, the math has flipped — buy is cheaper than build.
- 01
Selector breakage costs ≥ a sprint per quarter.
Either eng hours fixing parsers, or feature work blocked while you fix parsers.
- 02
You've had an account suspended in the last 6 months.
The ban roulette has stopped being a once-a-year nuisance — it’s a roadmap risk.
- 03
Your roadmap calls for a second LinkedIn surface.
You shipped enrichment, now product wants signals, Sales Nav, or engagement. Building a second surface from scratch hurts.
- 04
An enterprise customer asked for SOC 2.
Building a SOC 2-grade in-house scraper isn’t realistic. Vendoring is the cleaner posture for the security review.
- 05
Engineering is on rotation for LinkedIn changes.
You’ve added LinkedIn breakage to the on-call playbook. Time-to-recover is now a metric you track.
- 06
Your per-call cost is rising.
Proxy spend, account warmup, and incident time scale faster than you predicted. The “we’ll save money” thesis is breaking.
// Counterpoint
When build still wins.
We're not pretending Edges is right for everyone. Three cases where building yourself is the better call:
Massive scale, narrow surface
You process >10M profiles per month and your only call is one endpoint. Per-call cost dominates; engineering time amortizes; building is cheaper. Talk to us about enterprise rates first.
Hard data-residency rules
You're in a regulated industry where data cannot leave your VPC. Edges enterprise has region-pinned options, but for true on-prem you're better off building.
LinkedIn is a research project
You're a research lab and the scraper itself is part of the work — not a means to an end. Building teaches you things you can't learn calling an API.
// FAQ
Build vs buy, answered.
These are the questions we hear most from engineering leaders evaluating Edges.
How do you arrive at those engineering-hour numbers?
From 12 customer interviews who shipped in-house LinkedIn integration before switching to Edges. We asked for hours logged on tickets tagged "linkedin" or "scraper" over a 6-month window, plus on-call estimates. Median, not average.
Doesn’t building get cheaper as we scale?
Per-call cost does. But maintenance scales with surface area — every new LinkedIn page you parse is another set of selectors to babysit. The break-even sits around 10M calls/month for a single surface; signals and Sales Nav push it higher.
What about hybrid — Edges + some in-house?
Common pattern. Use Edges for the surfaces where reliability matters most (production CRM enrichment, Sales Nav) and keep in-house scrapers for one-off research workloads where breakage is acceptable.
What if Edges sunsets an action?
We version actions. Breaking changes ship behind /v2 with 12-month deprecation windows for paid plans, 6 months for free. The actions catalog has a public deprecation history.
Can we move data we collected via Edges to our warehouse?
Yes — every response is your data. Pipe to BigQuery, Snowflake, S3, whatever. We don’t restrict downstream use beyond the standard ToS.
What’s the typical buyer’s first sprint look like?
One sprint to swap one workflow (usually CRM enrichment) end-to-end. Dual-run for a week against the in-house scraper, verify field parity, cut over. The remaining surfaces come in subsequent sprints as roadmap permits.
The shortest path to a working LinkedIn integration.
Skip the eight-week build. Sign up and have an API key in your hand by the end of this paragraph.