By Kevin Mease, Chief Product Officer, Persado
The all-at-once AI rebuild is the single biggest threat to your time to market. And in my experience, it usually isn't marketing operations' plan.
Walk the floor of a large regulated marketing organization right now and you'll find two facts sitting on top of each other.
The first is that real AI work is already happening, and there is no architecture under any of it. Copy-paste into a chat window. Screenshots of creative. Personal accounts running alongside sanctioned ones. Some teams wired to connectors, some to code tools, some to nothing. Content designers producing both the copy and the final asset because that's faster than the handoff. Output is genuinely quicker than it was a year ago. None of it is repeatable, auditable, or measurable.
The second fact is that one floor up, a program has been approved to rebuild the entire marketing stack — the asset library, the image editor, journey mapping, offer serving, optimization, distribution — in parallel, in one release. Two years. Sometimes three.
Both descriptions are of the same organization, in the same quarter. That contradiction is the whole diagnosis. The copy-paste layer exists because people have campaigns to ship this week. The platform program exists because somebody promised an end state. Neither one is a plan, and the operations teams living in the gap between them generally know it. In my experience the all-at-once program usually isn't theirs.
Three reasons the all-at-once build doesn't finish
The instinct to rebuild the whole stack in-house is defensible on paper and brutal in practice. Three failure modes, and they compound.
The timeline multiplies. Building every service yourself, simultaneously, runs on the order of ten times longer to reach the end state than plugging in what already exists and replacing selectively. Read that as what it is: a program justified by the speed AI unlocks, structured so that speed arrives last. Teams are buying a slower route to going faster.
The risk profile is indefensible. Every dependency lands at the same moment and nothing is usable until everything is finished. There's no partial credit, no early proof, and no fallback when one workstream slips — and one always slips. When it does, you don't get a rollback of a component. You get a status update, and another quarter.
AI won't carry a monolith. This is the one that surprises people, and it's the most structural of the three. Past a certain codebase size, the system stops fitting inside any model's working context. AI accelerates bounded services with clean interfaces, where a model can hold the entire problem at once and reason about it. It does not make a large tangled system tractable. That constraint is not a temporary limitation of this year's tools — it's a property of building something no one, human or model, can see all of at once. You cannot generate your way out of it.
The headcount version of the same mistake
One more, because it almost always travels alongside the platform program: the assumption that AI means you need fewer engineers.
We use these tools heavily and I'm bullish on them. They are not at the point where they replace the engineering function. Even with a bench of genuinely excellent architects, you would still build on a services infrastructure — because the binding constraint isn't talent. It's the interface discipline that keeps a large system changeable after the people who built it have moved on.
Teams cutting headcount on the promise of AI gains, without first rebuilding their process, their tooling, and their stack, end up with worse output and half the people left to fix it. When the whole market speeds up, they will be hiring those people back, at a premium, into a mess.
The order that works
None of this is an argument against ambition. Rebuilding the stack is a legitimate goal. It's an argument about sequence, and the sequence is where these programs come apart. Four steps, and the order carries all the weight.
One: own the top layer. The interface and the interaction model are yours. That's where you differentiate, and it's the single thing no vendor can hand you. Can people log in? Can they see everything in one place? What does that clean interface actually look like? Answer that before anything else gets built. There are two ways to own it — build your own front end, or make the LLM itself your interface and switch on connectors. The second costs almost nothing to try, and most teams haven't priced it. That's the subject of the third piece in this series.
Two: inventory the services. Write down every service the stack needs, and how many there are. Mark each one differentiating or commodity. Most teams can't answer "how many services are there?" on the first ask — which means the program isn't scoped. It's funded, which is a different thing.
Three: plug in what already exists. Every capability you are not building this quarter runs on something you already own or can buy today. Modern systems are headless and API-accessible; Salesforce has said as much publicly, and any serious vendor can run behind an interface you control. Use your existing tools first and you have a working system in weeks instead of quarters.
Four: upgrade and replace, one service at a time. Pick the first service you want to own. Ship it. Then the next one. Because every service sits behind the same interface, replacing one is a swap rather than a re-architecture — and a build that disappoints becomes a quiet rollback instead of a stalled program and a difficult board conversation.
Five questions before anyone writes code
If you take one thing from this, take the diagnostic. These five questions, asked in a room with the people funding the work, will tell you inside an hour whether you have a program or an aspiration.
- How many services are there? If the number isn't written down, the program isn't scoped.
- Is the top layer in place first? The interface you own — built, or the LLM itself — is step one, not the last mile.
- What does the interaction model look like? Log in, see everything, act in one place. Describe it concretely, not as a principle.
- Which services are you building yourself, and why? "It's differentiating" is a real answer. "We prefer to own it" is not.
- Which one is first, and what runs in the meantime? Everything that isn't first should already be plugged in and working.
The ambition isn't the problem
I'll declare the obvious interest: Persado sells one of the services that shows up in that inventory. But the sequence above is the one I'd give a team that never buys anything from us, and I know that because large regulated brands have started asking us for exactly this — not a feature comparison, a point of view on how the pieces should fit. The answer doesn't change when we aren't in the picture.
What's short-sighted here isn't the goal. It's the belief that the end state can be reached in one motion, before anyone has counted the services or decided where the work starts. That belief is how a two-year program becomes a four-year one. And it's how the copy-paste layer downstairs survives long enough to quietly become the actual process — which is the outcome nobody funded and everybody gets.
