Roughly a third of the technical buyers we talk to now open with a version of the same question: why would I buy this when I could build it with Claude Code in a weekend?
It is a better question than it was a year ago. Agentic coding tools genuinely changed what a single competent person can assemble in a few days. Anyone who answers this with "building is hard, buy our thing" is not engaging with the actual state of the tooling, and technical buyers can smell that immediately.
So here is the honest version, including the cases where you should build.
What you can genuinely build in a weekend
Quite a lot, and it is worth being specific rather than vague.
A working prototype looks roughly like this. A list of target domains in a table. A scheduled job that pulls news for each one, hits a filings API for the public companies, scrapes careers pages for job postings. A model call that summarizes what it found and scores whether it matters. A Slack webhook that posts the interesting ones. Persistence so you do not re-alert on the same item twice.
With Claude Code, someone who knows their way around a terminal can have that running against twenty accounts inside two or three days. It will work. It will produce real signals. The first demo to your VP of Sales will go well, and the enthusiasm at that moment is genuine and justified.
The build-versus-buy conversation should start from that point, not from a pretence that the prototype is hard. It is not hard any more. What happens next is the actual question.
What breaks, roughly in the order it breaks
The prototype is not the product. Here is the sequence teams describe, and it is remarkably consistent.
Source coverage stops being a weekend problem. Twenty accounts on a news API looks fine. Then someone asks why an account that clearly announced something is showing nothing, and you discover the announcement was in a regional trade publication, or a podcast, or an earnings call Q&A, or a regulatory filing in a format nobody parses. Each additional source class is its own integration, its own parsing rules, its own failure modes. Signal quality is mostly a function of source breadth, and source breadth is where the work compounds.
Entity resolution turns out to be a real problem. Your list says "Acme." The news API returns articles about three different Acmes. A ticker symbol resolves to the wrong company. A subsidiary files under a parent name. This category of bug is unglamorous, never fully finished, and directly determines whether reps trust the output. We have hit versions of this ourselves.
Relevance scoring becomes the whole job. This is the one that surprises people. Pulling data is easy, and volume arrives fast. Deciding what matters is where the difficulty actually lives. One prospect told us plainly that in an evaluation, most of what a tool surfaced was irrelevant to their business, and that pulling lots of data is table stakes while relevant data is the bar. Another worried that ten articles about a single acquisition would push a low-priority account to the top of the list purely on volume. Both are scoring problems, and scoring is not a prompt. It is a thing you tune against feedback over months.
Nobody owns it. This is the one that ends most internal builds, and it has nothing to do with technology. The person who built it moves teams, gets promoted, or gets pulled onto a quarterly priority. The pipeline breaks quietly. Nobody notices for three weeks because a system that produces no alerts looks identical to a system where nothing happened. A founder we spoke to who had seriously considered building his own setup summed the whole calculus up in six words: "I don't have time for this."
The cost that does not appear in the estimate
When people estimate a build, they estimate the build. The build is the small part.
Ongoing maintenance is where the real cost sits: sources changing their formats, APIs deprecating endpoints, scoring drifting as your ICP shifts, someone answering "why did this account show nothing last week." None of that is intellectually difficult. All of it needs a name attached to it, indefinitely.
Then there is the cost of being wrong. If your scoring quietly degrades, you do not get an error. You get reps slowly deciding the tool is noise and going back to guessing, which is expensive and almost invisible until renewal season.
The honest way to run the numbers is not "engineer days times rate." It is: what is a fraction of an engineer's ongoing attention worth, forever, against a subscription. For most teams that comparison is not close. For some teams it genuinely is, which brings us to the cases where building wins.
When you should build
Three cases, and they are real.
Your signals are proprietary. If the thing that predicts a buying window at your company is in your product telemetry, your support tickets, or your usage data, no vendor has that. Build it. That is your edge and it should not be outsourced.
You have an unusual and stable definition of relevance. If what matters to you is a narrow, well-defined pattern that general-purpose scoring will never prioritize, and that definition is not going to change every quarter, a focused internal build can beat a general tool.
You have a platform team, not a person. If there is a team whose actual job is internal tooling, with on-call and a roadmap, the maintenance argument largely dissolves. Some larger organizations are in exactly this position and are building internal GTM platforms deliberately. That is a reasonable strategy.
Notice what is not on that list: "we have a smart engineer who is interested." That is how prototypes get built and abandoned.
See Salesmotion on a real account
Book a 15-minute demo and see how your team saves hours on account research.
The hybrid most technical buyers actually land on
There is a middle path, and in practice it is where a lot of the more technical evaluations end up.
Buy the data layer, build the logic on top. Take account intelligence through an API or an MCP server, then write your own scoring, your own routing, your own interface into whatever your reps already use. You skip the source-coverage and entity-resolution work, which is the part that compounds forever and produces no differentiation, and you keep control of the part that is specific to your business.
One prospect laid out his three options explicitly on a call: build it entirely with Claude Code, build a custom layer on top of a data API, or license something finished. He was right that those are the three options. The middle one is underrated, and it is the one that gets dismissed because build-versus-buy is framed as binary.
If you want to see what that looks like concretely, our MCP server exposes the intelligence layer to Claude directly, and the API does the same for your own code. Build whatever you want on top.
How to decide in an afternoon
Skip the spreadsheet. Answer four questions honestly.
Is the signal you need public, or is it yours? If it is yours, build.
Who maintains this in month six, by name? If you cannot name a person and they have not agreed, do not build.
What happens if it silently breaks for three weeks? If the answer is "nobody would notice," you have learned something important about how much you will actually rely on it.
Is the differentiating part the data collection, or what you do with it? It is almost always the second. Which is an argument for buying the first part.
None of that requires a decision about vendors. It requires being honest about what happens after the demo that goes well.
For the underlying economics, our build vs. buy analysis runs the numbers in more detail, and the DIY trap covers what happens to internally built stacks over a longer horizon.
