Build or Buy an AI SDR: Four Layers, Four Separate Decisions

Most teams make the build or buy call on an AI SDR as a single yes or no. One engineer prototypes a signal scraper over a weekend, it works on twelve accounts, and the question becomes whether to keep going. That framing is the problem. An AI SDR is not one product. It is four layers stacked on top of each other, and the economics of building are completely different at each one.

The pressure to build is real, and it is new. In McKinsey's 2026 global survey on AI, nearly a third of respondents (32 percent) reported that their organization had decided against buying one or more software products or features because they could be built internally with agentic coding tools. Coding agents made the first version of almost anything cheap. They did not make the seventh month of maintenance cheap.

What Does an AI SDR Actually Do?

An AI SDR is a system that does four jobs in sequence: it detects signals that a company may be entering a buying window, scores those accounts against your ICP, drafts messages grounded in the signal, and executes outreach across email and LinkedIn. Build or buy is a separate decision for each of those four jobs.

Bundling the four into one decision is what produces bad outcomes in both directions. Teams that buy everything end up with a score they cannot explain and no way to feed in the signals only they can see. Teams that build everything spend their engineering time on the two layers that reward it least.

Layer 1: Signal Detection Rarely Survives a DIY Build

Signal detection is the layer that looks easiest to build and is hardest to keep running. A parser for one job board is an afternoon of work. Coverage across dozens of sources, held steady over quarters, is the actual product.

Sources change their markup, move behind client-side rendering, add rate limits, or go away. Nothing errors when that happens. The pipeline keeps running and quietly returns fewer signals, and the first person to notice is a rep wondering why the account list got thin. Detection that nobody audits weekly decays without announcing itself, which makes it the worst possible thing to own as a side project.

There is a real exception. Build detection for the signals only you can see: product usage, support ticket themes, closed-lost accounts crossing a renewal date, or a niche public source specific to your vertical that no vendor has a reason to parse. A state permit database or a trade association member roster is a defensible edge precisely because it is narrow. For the broad set, the unstructured buying signals scattered across hiring pages, filings, podcasts and reviews, you are buying coverage and the maintenance behind it.

Layer 2: Scoring Is the Layer Most Worth Building

Scoring is where building pays off, because the inputs that make a score accurate are inputs only you have. Which signals preceded deals that closed, which ones preceded deals that stalled in procurement, how your cycle differs by segment: none of that is in a vendor's default model, which necessarily starts from a category average.

The honest caveat is volume. Calibrating weights against outcomes needs a reasonable number of closed deals to learn from. Below that, a model fit on a handful of wins is just noise with a decimal point, and considered manual weights on a short list of signals will beat it. Either way, the thing to insist on is an override you control and a score you can explain, which is also the difference between intent-based lead scoring that changes a decision and a number that sits in a column.

Layer 3: Message Drafting Is Cheap to Build and Expensive to Keep Good

Any competent engineer can wire a language model to a prompt template in a day. The cost shows up in what the model writes when the context is thin, because it will still write something.

Weak, and recognizable from any inbox: Hi Dana, I saw your company is growing fast and wanted to reach out. We help companies like yours scale outbound. Open to a quick chat?

Stronger, built from one observed signal: Hi Dana, you have three open roles across lifecycle marketing and revenue operations. That mix usually means retention and revenue process are moving up the priority list, and reporting tends to get harder before it gets better. If that is roughly right, I can show you how teams at that stage track expansion signals without adding another dashboard. Worth fifteen minutes?

The second message works because it names a fact that can be verified, presents the interpretation as an interpretation rather than a claim about Dana's priorities, and sizes the ask to the strength of the evidence. Getting one message to that standard is a prompt engineering exercise. Getting the ten thousandth one there is a guardrail problem: something has to catch the stale signal, the unsupported inference and the wrong persona before the message sends, which is the work described in AI SDR guardrails. That review layer is the part DIY builds skip, and it is the part that protects the domain.

Layer 4: Sending Is Where Build Decisions Get Expensive

The sending layer runs on rules you do not control, and the penalty for getting them wrong lands on your domain and your reps' accounts rather than on a dashboard.

On email, Gmail's sender guidelines set the floor: authenticate with SPF and DKIM, publish a DMARC record, support one-click unsubscribe once you are sending in bulk, and keep the spam rate reported in Postmaster Tools below 0.30 percent, with under 0.10 percent as the target. Senders above 5,000 messages a day to personal Gmail accounts carry additional requirements. Those are thresholds a build has to monitor continuously, not configure once.

On LinkedIn, the constraint is the platform's own terms. LinkedIn's User Agreement prohibits developing, supporting or using software, scripts, robots, crawlers or similar means to scrape or copy the service, including profiles and other data. That applies whether you build or buy, which is exactly why it belongs in the decision: the question is who is accountable for staying inside the rules and who absorbs the cost when a rep's account gets restricted mid-quarter.

Add warmup schedules, sender rotation, reply and bounce classification, and stitching a LinkedIn thread to an email thread for the same person, and the sending layer turns into an operations function. Few teams set out to staff one.

Four Questions to Ask Before You Build Any Layer

Run each layer through the same four questions, and the answer usually stops being a debate.

• Is the input something only we can see? If yes, build it. No vendor can buy its way to your product usage data or your support queue.
• Does this layer get better with our outcome data? If yes, build it, or at minimum own the override and the explanation.
• Does the layer break when something outside us changes? If yes, buy it. Maintenance under external change is a standing staffing commitment, not a project with an end date.
• Who owns this in month seven? Name the person. If the honest answer is the engineer who built it, between other priorities, you have acquired a dependency rather than built a capability.

Layer one fails questions three and four for most teams. Layer two passes one and two. Layer three passes nothing cleanly, which is why it tends to get built badly and then quietly replaced. Layer four fails question three hardest of all.

The Hybrid Most Teams Land On

The usual endpoint is to buy detection and sending, build the scoring overlay, and feed in your own first-party signals. That split follows the four questions rather than a preference about tooling.

It has one failure mode worth naming. When a bought platform fires the first touch and a homegrown workflow handles the follow-up, the signal that triggered the sequence has to travel with it, or the second message reads as though the first never happened. Keep one system of record for the triggering signal, and make every follow-up read it, which is the discipline behind turning a signal into an outreach sequence at all.

Where Alsona Fits in a Bought Stack

Alsona is built for the two layers that punish building. It monitors 32 intent signals across hiring, advertising, technology, funding, reviews, social and company activity, which you can browse in the signal library, so detection coverage and its upkeep are not your team's problem. It scores every lead against your ICP with the reasoning shown and returns a ranked list of accounts to work, which is the input your own weighting sits on top of rather than a black box replacing it. From that context it drafts individualized LinkedIn and email messages, runs both channels, and keeps the replies in a unified inbox.

If you want to test the detection layer before committing to anything, run a few accounts you already know through Alsona's free signal extractor and compare what comes back against what your reps already found by hand.

The Takeaway

Stop asking whether to build or buy an AI SDR. Ask it four times, once per layer, and answer each with the four questions above. The pattern most teams arrive at is to buy the layers that break when the outside world changes and build the layers that improve with their own data. That is a defensible stack. A single yes or no, made on the strength of a weekend prototype, usually is not.

Build outbound around signals you can point to, with a score you can explain. See how Alsona turns intent signals into outreach.