Ask an AI coding tool to build you a website, and it's a widely recognized enough pattern to have its own name: you'll often get back a purple-to-blue gradient hero section, rounded cards with a soft shadow, and a headline that opens with "Elevate your workflow." Ask a different AI tool, or a different person using the same tool, and you'll frequently get something that looks strikingly similar. People online catalog the specific recurring patterns, and the phenomenon has a nickname: AI slop, or more specifically here, the "AI purple problem."
It's worth understanding exactly why this happens, because the same underlying mechanism, not the purple gradient specifically, but the reason it exists, shows up in business automation too. A workflow built from a template can look thoroughly custom while actually treating your business identically to every other client who bought the same package. Knowing the mechanism is what lets you tell the difference.
Why AI-generated design converges on the same look
The specific, common explanation is worth getting right, because the accurate version teaches a better lesson than the popular shorthand. It's often said that Tailwind or shadcn, the styling tools underneath most AI-generated web interfaces, simply default to purple. That's not quite accurate: shadcn's actual default primary color is a near-black, essentially colorless tone, and Tailwind ships more than twenty color families without designating any of them as a default choice for anything. Neither tool told anyone to use purple.
One widely cited explanation, discussed in HTTP Archive's Web Almanac 2025, points to training data rather than any tool's default setting: Tailwind's own co-creator, Adam Wathan, has suggested that purple was heavily used across Tailwind's documentation and marketing pages around the time major AI training crawls captured that material, which could plausibly have nudged models toward associating purple with "a well-built site" during training. It's worth being honest that this is a hypothesis about a training-data artifact, not a settled, proven cause: the same Web Almanac analysis looked at actual, real-world Tailwind sites and did not find a clear rise in the use of indigo, violet, or purple tones after ChatGPT's release, which complicates a simple, confident version of the story. What's genuinely well established is the effect, not a fully confirmed explanation for it: people online have named and cataloged the recurring pattern, with detailed inventories listing the exact recurring tells, the gradient, the rounded corners, the centered three-card layout, the "Elevate your workflow" copy, consistently enough that tools now exist specifically to detect and strip them back out.
The same mechanism, applied to automation instead of design
Here's the part worth translating directly to business automation, as an argument rather than a separately documented finding: a pre-built automation template has its own equivalent of the purple gradient. No-code workflow templates and packaged "AI automation" offerings ship with default trigger conditions, default escalation logic, default categorization schemes, and default notification wording, decisions somebody made once, for a hypothetical median business, that then get reused across every client who buys the package. Customizing any of those defaults takes real effort. Accepting them takes none. That same asymmetry, whatever requires the least additional work tends to win by default, is the part of the design story that transfers cleanly, regardless of exactly how the purple gradient itself came about.
The result looks like automation happened. A workflow is running, notifications are firing, tickets are getting categorized. But the same way a purple gradient signals "nobody made a specific design decision here," a workflow whose trigger conditions, escalation rules, and edge-case handling would be identical whether it was built for a dental practice or an accounting firm signals that nobody made a specific decision about your business either. It's not that the automation doesn't work. It's that it wasn't built to work for you specifically, and the gap between those two things tends to show up exactly where your business differs from the median case the template was built for, a mismatch that shows up in why AI projects fail more broadly too.
What this actually looks like in a business automation
A few signs tend to show up consistently in templated automation, worth checking for directly rather than assuming a working system is a custom one.
The workflow handles the obvious, high-volume case well and handles almost nothing else. Ask what happens when a customer's request doesn't fit the expected pattern, and if the honest answer is "it breaks, gets miscategorized, or goes nowhere," that's the automation equivalent of a purple gradient: fine for the median case, untested for anything specific to how your business actually operates.
The notification and escalation logic reads generically. If the wording, thresholds, and routing rules could describe literally any business in your general category without modification, they probably weren't written with your specific business in mind, even if they were technically configured inside your specific account.
Nobody can point to a decision that was made because of something specific to your business. This is the most direct test. A genuinely custom build has at least a few points where the builder made a call because of something particular to how you operate, not because that's what the template does by default.
A framework for telling the difference
This is a Kubera AI planning heuristic, not a universal test, meant to give you concrete questions to ask a vendor or integrator rather than a way to be certain from the outside.
The Kubera Template vs Custom Filter asks three questions about any proposed or existing automation:
- What happens on your specific edge cases, not the obvious case? Describe two or three situations that are unusual for your business but real, an order that doesn't fit the standard pattern, a client type your competitors don't have. A templated system tends to have no good answer. A custom one should.
- Can the vendor point to a specific decision made because of your business, not because it's the default? If every answer to "why does it work this way" is some version of "that's how it's configured," rather than "we built it that way because of X specific thing about how you operate," you're likely looking at a template with your logo on it.
- Would this same workflow, unmodified, work almost as well for your direct competitor? If yes, it probably isn't capturing whatever makes your specific process different from theirs, which is usually exactly where the real value in automating a process lives.
None of this means templates or no-code platforms like n8n, Make, or Zapier are bad. Plenty of genuinely well-built automation starts from a template and gets meaningfully adapted from there, the same way a good AI-assisted website can absolutely avoid the purple gradient if someone deliberately steers away from the default. The problem isn't the starting point. It's a build that never moved past it.
Where this plays out in practice
Illustrative scenario, not a specific Kubera client: a mid-size business buys a packaged AI automation for customer support ticket routing, and it appears to work well for the first month, tickets get categorized and routed, response times improve. Three months in, the business notices a recurring category of customer request, specific to a product line only they sell, that the system consistently miscategorizes or routes to the wrong team. The workflow was never actually built with that product line in mind; it was built for whatever generic support categories the template shipped with, and the business's specific case simply wasn't part of the median the template was designed around. Rebuilding the categorization logic around the business's actual product structure, rather than the template's generic categories, fixes a problem that was invisible until the exact case the template didn't anticipate showed up.
FAQ
Is it bad to start an automation project from a template? No. Templates are a reasonable, often sensible starting point. The problem is when the build stops at the template rather than adapting it to what's actually specific about your business, the same way a purple gradient isn't inherently wrong, it's a problem specifically when it's the only choice anyone made.
How do I know if my current automation is templated or custom? Ask what happens on a few specific, real edge cases unique to your business, and ask whether anyone can point to a decision made because of something particular to how you operate. Generic answers to both are the clearest sign.
Why does this matter more for automation than for a website's color scheme? A purple gradient is cosmetic. A workflow that doesn't match how your business actually operates produces wrong categorizations, missed edge cases, and silent failures in exactly the situations a template wasn't built to anticipate, which tend to be the situations that matter most.
Is this the vendor's fault, or is it inherent to no-code platforms? Neither, exactly. It's an economic pattern: customizing a default takes more effort than accepting it, and that pressure exists regardless of the specific tool. The question is whether the effort actually got spent on your specific case, not which platform was used.
What's the AI purple problem, exactly? A widely recognized pattern where AI coding tools frequently produce a purple-to-blue gradient and a specific set of recurring design choices, not because any underlying tool set that as a default. The leading explanation points to something in the training data, possibly related to how heavily purple was used across widely crawled design documentation, but this is a discussed hypothesis rather than a fully confirmed cause.
Can a templated automation still deliver real value? Often yes, for the median case it was built to handle. The risk isn't that it delivers no value, it's that the value it delivers is capped at whatever the template's designer anticipated, which usually doesn't include whatever makes your business specifically different from a competitor's.
How much customization is actually necessary to avoid this trap? There's no fixed amount. The test in this article, whether someone can point to a specific decision made because of your business rather than the default, matters more than a percentage of the build that's been changed. Starting with the right process in the first place, covered in How to Choose Your First AI Automation Project, makes this easier to get right from the start.
Does this apply to AI chatbots and agents too, or just workflow automation? The same mechanism applies. A chatbot with generic, unmodified default responses and escalation logic has the same problem as a workflow with default routing rules, it works for the case everyone has in common and struggles with whatever makes your business specific.
Should I ask my integrator these questions before or after signing a contract? Before, ideally. Asking a vendor to walk through a specific edge case from your business, before committing, is a low-cost way to see whether they're proposing to adapt to you or asking you to adapt to their template.
Is a fully custom build always better than starting from a template? Not necessarily, and it's usually more expensive and slower to deliver. The right question isn't template versus custom in the abstract, it's whether whatever gets delivered, template-based or not, actually reflects specific decisions about your business rather than a default applied uniformly.
If you're trying to work out whether a proposed or existing automation actually reflects your specific business, or whether it's a template wearing your logo, that's exactly the kind of question worth asking before signing off on a build.