By Kevin Mease, Chief Product Officer, Persado
Every marketing organization is now making a build-or-buy call on a dozen AI capabilities at once. Most are making it backwards.
Here's a decision from outside marketing that makes the point cleanly.
Search-ranking data used to mean one suite, at roughly $600 to $700 a month. Replacing it with three specialist services — one at $75, one at $50, one at $25 — cut the bill to about $150 and improved the data. Nice outcome. But the price is the least interesting thing about it.
The interesting thing is that nobody in that position is ever going to rewrite those services. Doing it means running a hundred web crawlers, standing up the index, and maintaining the database infrastructure underneath. Not because the code is beyond a good team — the code is the easy part — but because the product is the accumulated crawl. You would be starting the accumulation from zero on the day you shipped.
That's what you're actually buying when you rent a specialist service: someone else's economy of scale. When a vendor does one thing exclusively, at volume, across many customers, their marginal cost sits structurally below your fully loaded engineering cost, and it always will. That's true for search data. It's true for any service where the hard part is the accumulated data and the models trained on it.
Three ways to source every service
Once a capability sits behind a clean interface, how you build it matters far less than that it works. Every service can be sourced one of three ways, and the right answer differs service by service — which is precisely the discipline that gets skipped when a stack is planned as one program.
Build it where the capability is genuinely differentiating, proprietary to your business, or where nothing adequate exists on the market. Use this when it's core intellectual property or a true competitive edge, and when you can staff it without slowing the rest of the roadmap.
Use an open component for commodity capabilities that are already well solved, where you want control and flexibility without starting from zero — and where you have the team to maintain what you adopt.
Tap a paid service where a specialist already outperforms what you would build, and owns the roadmap, the data, and the results. Use this when speed matters, the domain is hard, or the vendor's outcomes beat anything realistic for you to build.
None of these is a moral position. The failure mode I see isn't choosing wrong on one service. It's not choosing at all — deciding "we build" or "we buy" as a posture, once, for everything.
The test that sorts them
Own it when it's the interface your people and your customers touch. When the logic encodes something proprietary about how your business works. When your first-party data is the asset and it can't leave. When you can staff it without slowing everything else down.
Rent it when the hard part is accumulated data or trained models rather than code. When a specialist's marginal cost is structurally below yours. When the domain carries its own compliance or regulatory surface. When what you'd actually be doing is maintaining infrastructure rather than building product.
Run your inventory through that test honestly and most stacks come out inverted from how they're currently planned. Teams build the commodity — another asset library, another journey tool — because it's tractable and visible. Then they rent the thing that actually differentiates them, or worse, try to rebuild it and discover eighteen months in that the code was never what they were missing.
Where language performance falls
Which brings me to the service I know best, and where I have an obvious interest to declare.
Every model writes fluent copy now. That was never the hard part, and it stopped being a differentiator the moment frontier models became something anyone can license by lunchtime. A capability your competitor can rent this afternoon is not an advantage. It's a subscription.
The hard part is knowing which words moved which people to act — in your category, under your regulator, for your customers — and being able to tell before you send. That is not a code problem. It's an accumulation problem. It's built out of campaigns that ran, outcomes that were labeled, and language that was tested against a control and either won or didn't. Ten years of it, in our case: more than 120,000 performance-labeled campaigns, and 20-plus regulatory frameworks built into how the language is generated rather than checked afterward.
You cannot generate your way to that. It accrues, or it doesn't exist. Which puts language performance squarely in the rent column of the test above — the hard part is the accumulated data, the domain carries its own regulatory surface, and a specialist doing only this, at volume, across many regulated brands, has a marginal cost you will not match with an internal team.
I'd make the same argument about several services I don't sell. Identity resolution. Deliverability infrastructure. The reason it lands harder here is that language performance feels buildable in a way crawling the web doesn't. Anyone can see the output. Copy is words, and words look like something a good team with a good model could produce. The output is the easy part. The judgment about which output to send is the decade.
The line one client drew for us
The cleanest version of this division of labor I've seen, a client drew themselves, unprompted, while describing their target architecture.
Their decisioning engine owns who to reach, which offer, which channel, what frequency, when to suppress, how to sequence the journey. That's their first-party data and their business logic. Build it — it's the definition of proprietary.
The content service owns what the message actually says, how well that language performs, whether it holds brand voice, whether it clears compliance, and what the results teach the next send. Buy it — the hard part is accumulated outcomes and a regulatory surface, not code.
What makes that line valuable isn't the split itself. It's that the two sides are independent. Change decisioning vendors and the content service is untouched. Change the content service and the decisioning logic never moves. That's the entire payoff of putting each capability behind a clean interface: the sourcing decision stops being a bet and becomes reversible. Launch on vendors and open components, prove the workflow, then replace any single service with your own build later, with no disruption to anything above it.
"Buy now, build later" is only a coherent strategy if the architecture makes it cheap to change your mind. Composed as services, it is. Built as one program, every sourcing decision is permanent whether you meant it to be or not.
Build where you differentiate
The short-sighted move in this market isn't buying too much or building too much. It's answering the question once, at the level of the whole stack, when it's twelve separate questions with twelve different answers — and then spending the differentiating budget on the commodity layer while renting, or attempting to rebuild, the part that took someone else ten years to accumulate.
Write down the services. Run each one through the test. Build where you genuinely differentiate, rent where the hard part is somebody else's decade, and keep the interfaces clean enough that you can change your mind about any of it later.
The code was never the hard part. It's the thing that looks like the hard part, which is why so many teams end up building it.
