Stop Putting Vendor Names in Your Marketing Copy

Last week we pulled every vendor name out of our site copy. n8n, Zapier, make.com, the framework mentions on the about page. All of it.

The immediate reason was practical: n8n lapsed in July. We had a hero badge on the homepage reading "Built on n8n + Claude" for a tool we stopped running two months prior. That's the obvious fix.

But the deeper problem was that vendor citations age badly regardless of whether you keep paying. A client doesn't care that the commodity data feed runs on a particular workflow tool. They care that the price is current when their rep opens the app. Naming the vendor underneath it adds maintenance surface without adding clarity.

What We Replaced It With

The old about page listed stacks: "Next.js + Supabase," "PHP + Airtable backend." The new version describes what each system does instead.

Before: "AI-powered soil asset valuation portal (Next.js + Supabase)" After: "Soil asset valuation portal with AI agents inside it"

Before: "n8n workflow automations for daily standups, content, and handoffs" After: "Internal operations systems that run a business day to day"

The second version is more accurate because it describes the outcome, not the implementation. If we swap the persistence layer next year, the copy doesn't break. If a client asks what it does, the answer is in the copy, not a follow-up question about what n8n is.

The File That Would Have Re-Infected Everything

Pulling vendor names from the site was the easy part. The real risk was src/content/brand-voice.ts.

That file is the source document for how we generate marketing copy. It had this instruction: "Reference real projects: MCP servers, n8n automations, AI portals." Every time an AI agent wrote copy from that brief, it would reach for those specific terms. The site copy gets clean, someone runs a copy generation pass six months later, and the vendor names come right back.

We rewrote the instruction: "Reference real projects by what they do, never by the vendor stack under them." The projects list in that file now reads as outcomes, not tools.

That's the one that would have bitten us. A rule that lives in your content brief is active every time you generate content. A rule that only lives in a Notion doc or someone's memory is inactive whenever they're not in the room.

Why We Build Custom Anyway

This matters beyond avoiding stale copy. We don't resell someone else's automation platform. When we build a workflow system for a client, we build it. The behavior, the logic, the integration points. Citing a vendor as the capability implies the vendor is the service and we're the middleman. That's not how it works.

If we told a client "we built your operations system on n8n," the question that naturally follows is: "Do I need to pay n8n too?" The answer gets complicated. If we say "we built your operations system," the answer is simple.

The copy catches up to the actual offer.

One Rule in the Source of Truth

The change that matters most isn't any individual file. It's the rule we added to brand-voice.ts: "We build everything custom, never position on someone else's tool."

That rule lives in the same file that shapes every AI-generated content pass. It's active every time we generate marketing copy, service descriptions, or project summaries. We don't have to remember to enforce it because it's in the input.

That's the fix that lasts.