Stop vibe coding your marketing tech stack: Your marketers will thank you
I’ve never experienced a year like this in my career. The rapid acceleration of AI between the first of the year, and today, is astounding. And now, I’ve recently learned a term which will probably become a staple as the year progresses. Vibe-coding. And that people want to vibe code their tech stacks, instead of buying out of the box.
this is a real pic of me, sitting at a table, asking people to change my mind
A vibe-coded tool is a pet project. A side build. Something an engineer (or now, really anyone) creates for their own team, with good intentions and some real smarts, but little long-term thinking. It might be a Notion/Retool/Zapier Frankenstein. It might live on a private repo. It probably doesn’t have documentation. And it certainly isn’t going to be something they’ll enjoy maintaining with marketer one-off requests.
It’s the age-old story of an engineer getting an idea, and then not wanting, or not having bandwidth in 1 week's time, to help any further. Sorry, I’m stereotyping, but we’ve all been there… right?
And more often than not, the tool gets handed off to marketers and non-technical teams with the assumption that “you’ll figure it out.”
Why I’m hating on vibe-coded tools
Transparently, I’m obsessed with Lovable and Cursor. My discovery of these two tools a few months ago made me feel so giddy, I spent a whole afternoon ‘vibe-coding’—feeling completely invincible. Is this how engineers feel when they bring products to life?!
This new world of AI-supported growth I can only imagine will bring brilliant ideas to life that were previously unrealized or gated to the technical. But, I feel that these ideas require a start from scratch state, vs. a rebuild of something that exists already.
My fear when I encounter individuals claiming they will build their own data platform, or marketing automation hub is all consuming. I fear for the data, I fear for the lack of scalability of the platform as we progress into the year, and I fear for the marketer end user…unfortunately slapped with a platform that probably only accounts for 10% of the dream must have list.
I am a hypocrite, because I am completely obsessed with the tools I vibe code myself, for myself, but hate on the tools that others create for teams and for large-scale initiatives. Maybe this is how we all feel in a way…stuck in a silo convinced that the individual tools we create are the perfect solution for everyone—when in reality, they aren’t.
Why They’re Breaking Everything
Vibe coded tools will be either a security teams nightmare, or a bounty hunters’s lottery win in the near future. But they also come with serious faults.
They're not scalable—by design.
These tools weren’t built to last. They were built to scratch an itch, not support a team, grow with a business, or adapt to shifting priorities. Versioning? Access control? Support workflows? Nah.Yesterday’s requirements ≠ tomorrow’s reality.
The MVP might work today, but marketing teams evolve. Lifecycle programs grow. Channels diversify. Suddenly your quick-fix tool can't handle segmentation, localization, or even basic permissions. And the original builder? Probably already onto the next project, or worse, their next company.Your competitors are skipping the tool—and building the relationships.
While you’re debugging a half-broken interface to send an email campaign, your competitors are in-market, testing messaging, and building pipeline. Internal tooling should remove friction, not introduce it.There are hidden costs everywhere.
Lost time. Rewrites. Team churn. The cognitive load of onboarding someone new into a system only one engineer understands. And let’s not even start on what happens when that engineer leaves.
Don’t Fall for the AI Shortcut
Yes, AI has made it easy to build. But that doesn’t mean you should. What feels fast and clever now will feel limiting and frustrating later—especially for teams that don’t speak code.
Instead of spinning up another internal tool to “just do the job,” ask:
Is there an out-of-the-box solution built for this use case?
Can I involve the actual end users (hello, marketers) in the build process?
Will someone still be able to maintain this in six months?
Will I actually WANT to help continue to build this product in 3, 6, 9 months? Do I have anything else going on that would prevent me from helping?
The Fix? Build With, Not For
If you must build internal tools, do it collaboratively. Pair engineers with the teams who will use the tool. Document everything. Assume you’ll need to onboard someone new every quarter.
Or better yet—admit that “build vs. buy” is really about buying time. Time to focus on strategy. Time to get into market. Time to scale.
Because no one remembers the internal dashboard that almost worked. They remember the teams that shipped campaigns, crushed targets, and moved fast.
And the ultimately solution? If you want something. Ask for it. Yell about your feature requests, put pressure on your vendors, and dream big. But don’t assume that your vibe coded solution is going to be what’s best for those beyond you.