You Don't Have a Productivity Problem. You Have a Build vs. Buy Problem.

Something I don’t see people talking about enough in the AI enablement space right now is how to evaluate where you should build a custom workflow or solution using AI coding tools versus when you should just buy something that already exists.

I think this makes sense. When new technology comes out, everybody rushes to figure out how they can use it. There’s a lot less “should we use it for this?” and a lot more “what can we use it for?” But I would argue that there’s a meaningful amount of productivity drain happening when people start using these tools, disguised as productivity gains. And I don’t think I’m the only one noticing it.

A recent METR study found that experienced developers using AI coding assistants actually took 19% longer to complete tasks than when they worked without AI. The most striking part? Those same developers believed AI had sped them up by 24%. That perception gap is telling. It’s the same dynamic I see playing out in marketing right now: people feel more productive because the work feels more impressive, more technical, more novel. But the output and the outcomes haven’t changed proportionally.

This all feels very familiar to me.

• I spent a number of years at one of the largest media companies in the world, working with data science teams to develop proprietary algorithms for media management. We built custom technology to automate things like programmatic display and paid search buying decisions, and we were able to consistently beat off-the-shelf solutions like Google’s DoubleClick at the time by about 20%.
• There was probably a 10-year period of my career that was characterized almost exclusively by large digital transformation projects with organizations like American Express, Verizon, Novant Health, and UnitedHealth Group, modernizing their marketing programs by getting them into algorithmically driven automation tools.

I learned something important during that time. The conversation that happened before every build decision was the most important conversation we had.

The conversation nobody is having

In a product engineering environment, before you decide to build anything, the team sits down and thinks through a set of questions.

• What is the user actually trying to achieve?
• What’s available on the market?
• What’s the existing tech around it?
• How is the person going to use it?
• Do we need something different enough from what we can buy on the open market to justify deprioritizing something else we could build this quarter?

This is muscle memory for anyone who’s worked on a software engineering or product management team. But most of the people picking up AI coding tools today haven’t had to make decisions like this before. They’re marketers, founders, operators, consultants. They’re unfamiliar with the pattern itself, which means they skip it entirely.

And I get why. There’s an immense sense of reward when you build something technical with these tools. You put together a social scraper with a Google Sheet and some API connections, you wire up a LinkedIn tracker, and suddenly you’re thinking, “Software engineers could never. Wait until my dev team sees this.” That dopamine hit is real. The problem is what happens next.

You sink a week into building the tool. Testing it. Improving it. Squashing bugs. You get it to a point where it produces something useful. Then the next week you use it a couple of times, and it’s accomplishing maybe half of what you originally had in mind. You keep iterating, keep investing time, and eventually you have something that works for your specific use case. Sort of. And you’ve spent 20 or 30 hours on it that could have gone toward billable work, new business, or building something with actual enterprise value.

This pattern has a name in the software world. It’s called “tech debt”. Stripe’s Developer Coefficient report found that developers spend up to 33% of their time managing it. McKinsey estimates that technical debt increases software maintenance costs by up to 60%. And CISQ’s Cost of Poor Software Quality Report puts the annual cost to U.S. companies at $1.52 trillion. That’s not an enterprise-only problem. That’s a structural cost of building things without evaluating whether you should.

Alex Turnbull, the founder of Groove (which he bootstrapped to $5M ARR), spent a year building two AI-powered products using vibe coding and AI assistants. His conclusion was blunt: AI coding tools got him to something that looked finished but couldn’t produce a finished product. He estimates that roughly 10,000 startups attempted to build production apps with AI assistants in 2025, and more than 8,000 of them now need rebuilds or “rescue engineering” costing $50K to $500K each. Gartner predicts it will get worse before it gets better: by 2028, prompt-to-app approaches adopted by citizen developers will increase software defects by 2,500%, triggering what they call a “software quality and reliability crisis.” The tools accelerate building. They don’t accelerate building well.

What “free” actually costs

My favorite argument for custom development is that it’s “free.” Nothing is free, especially not custom-engineered software. You paid your own time to develop it. It took much longer than you expected. There was a real opportunity cost to the things you didn’t build or do instead. You’re going to need to train yourself (and maybe your team) on how to use it. And then you’ve entered into a continuous software management, improvement, development, maintenance, and bug-fixing state for something you’ve built internally. Forever. Or at least until you stop using it.

I lived this firsthand. At one point, we went through the painful process of building our own CDP. It took a year to get to an MVP state. We rolled it out and it could do maybe 50% of what off-the-shelf CDPs offered, but it was “free.” Except it wasn’t. We had to pay engineers to develop it. We had to train the teams on how to use it. They needed support, retraining, and retraining after that. And there was constant pressure to keep building on top of whatever the MVP was to fulfill the full use case.

I ran into a similar situation recently with my own work. I was building a social listening and competitive tracking tool using Claude Code. I had this vision of a scraper that would monitor top profiles on LinkedIn, track what they were posting, surface trending content, the whole deal. I got deep into it. It was genuinely cool. And then I realized something: the approach I was using couldn’t even track LinkedIn, which is my biggest channel. The entire build was structurally limited in ways I hadn’t evaluated before I started.

When I challenged myself to look for a buy solution (something on the open market that solved the same problem), the conversation shifted. How much would it cost to just buy a tool that does this? Seventy dollars a month. Could I save or make more than seventy dollars a month by not building and maintaining this myself? Obviously. So I bought the tool and moved on.

Gartner’s 2025 Marketing Technology Survey found that martech utilization has dropped to 49%, meaning companies are using less than half the capability of tools they’re already paying for. Meanwhile, 26% of martech budgets are wasted on underused tools. The irony is that many people building custom replacements for marketing tools are doing so because they perceive the tools as too expensive, while simultaneously investing hours worth far more than the subscription cost.

The three outcomes worth knowing about

Here’s the framework I use now, and it’s the same one I’ve watched engineering teams use for years. Before you build anything, go look at the open market first. One of three things will happen.

1. You find an off-the-shelf solution that fits your use case, integrates with your existing tools through an API or MCP connector (or even something simple like bulk exports and imports), and it’s affordable enough that buying it makes clear sense. You buy it. It’s already built. It’s reliable. It works with everything else. And now you have 10 to 20 hours back over the next few weeks to build something that actually generates enterprise value or personal value for you.
2. You search the market and find that nothing really works. The existing solutions are too expensive for what they deliver, or they don’t solve your actual problem. And that’s a fascinating discovery in itself, because now you’re looking at a potential market opportunity. If nothing exists that solves this problem well, maybe this is something you can build and sell to other people like you. That’s a cool outcome.
3. You find a tool that accomplishes 80 to 90% of your use case. Not the full 100%, but enough to get you to value fast. You buy it, get the core functionality running, and then do custom development on the remaining 10 to 20% to make it truly yours. Instead of building 100% from scratch, you’re building a small layer on top of a stable foundation.

I saw this play out at Healthline Media when we were developing our own e-commerce properties. We needed an easy way to manage thousands of SKUs with merchandising information, and we were working through a band-aid solution powered by Google Sheets and Fivetran table connections. Our engineering team did something smart: instead of immediately jumping into a build, they committed a couple of sprint cycles to researching publicly available solutions. They came back and said, “There’s this tool called Retool. It can do nine out of ten things you need. The one thing it doesn’t solve doesn’t matter that much. Let’s buy a Retool license, integrate it into our CMS, and build the 10% of custom functionality over time.” It solved our use case in days versus weeks and saved us a ton of ongoing maintenance.

A word of caution on the highlight reel

I see a lot of activity on LinkedIn, YouTube, and Twitter from people showcasing complex things they’ve built with AI coding tools. “Look at this social scraper.” “I built a competitive intelligence dashboard.” “This will save you hundreds of dollars a month on a tool.” Most of it is genuinely impressive. And for someone in a pinch who’s just trying to validate a business case before they can make a bigger investment, or a solopreneur who truly can’t afford another subscription, I completely see the value.

But as someone who has spent fifteen years purchasing, building, and maintaining marketing software of all different types, I look at most of those builds and think: that is one more piece of technology you have to maintain every day— are you certain that it will do a better job than what you are doing now on either a “time saved” or an “outcome produced” basis?

The most effective organizations I’ve seen don’t default to building. They default to evaluating. MIT Sloan’s framework calls this “buy, boost, or build,” and the research is clear: success depends less on which path you choose and more on having a clear framework for choosing. McKinsey’s State of AI report found that 30 to 40% of potential AI impact is lost to fragmented systems, misaligned incentives, or insufficient operating model redesign. The problem isn’t the tools. It’s the decision-making around them. That’s the piece most people are missing.

What to do?

Before your next build, take five minutes with this process. Seriously, five minutes.

1. Write down the use case in one sentence. What is the business outcome you’re trying to achieve? Not the tool you want to build. The outcome.
2. Search the market. Spend fifteen minutes looking at what exists. Check G2, Capterra, Product Hunt. Ask in a community. Look at what tools your peers are using. You might be surprised by what’s out there for $50 to $100 a month.
3. Run the math. If the tool costs $70 a month and you’d spend 20 hours building a custom alternative, you need to honestly ask: is your time worth less than $3.50 an hour? Because that’s the trade. And that doesn’t account for the ongoing maintenance, bug fixes, and feature additions you’ll need to invest in perpetually.
4. Check for the hybrid path. If something gets you 80% there, buy it and build the 20%. That’s almost always faster and more reliable than starting from zero.

I’ve actually built a downloadable decision framework for this. It’s a prompt you can run in the LLM of your choice (Claude, ChatGPT, Gemini, whatever you prefer). It walks you through understanding whether something is a build or a buy in about five minutes. It’s designed so that from now on, when you have an idea of something to build with your AI coding tools, you can take a few minutes to evaluate it properly and then move forward with confidence. The work you do in your AI coding tools should be making you more money, not creating more tech management work. Access the prompt here.

And if this whole conversation feels like the tip of an iceberg (the tools, the workflows, the decisions about what to build and what to buy, the stack that ties it all together), that’s because it is. MultiplAI Growth Systems is an AI enablement and growth engineering consultancy that helps agency owners and fractional marketing leaders increase billings and client retention by modernizing their practices with AI tools, skills, and workflows. See if you’re a candidate for our service by visiting our website and getting a free digital diagnostic. It takes ten minutes, and it might save you months of building the wrong things.

Sources mentioned in this piece:

METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025). Stripe, "Developer Coefficient Report."

McKinsey, "Technical Debt and Software Maintenance Costs."

McKinsey, "The State of AI in 2025." CISQ, "Cost of Poor Software Quality Report" (2022)

Gartner, "2025 Marketing Technology Survey"

Gartner, "Predicts 2026: AI Potential and Risks Emerge in Software Engineering Technologies"

Retool, "2026 Build vs. Buy Report"

Fortune, "AI Productivity Paradox: CEO Study" (Feb. 2026)

MIT Sloan, "Buy, Boost, or Build: Choose Your Path to Generative AI"

Alex Turnbull, "The Vibe Coding Delusion" (TechStartups.com, Dec. 2025)

Arvid Kahl, "Vibe Coding Won't Kill SaaS" (TheBootstrappedFounder.com, 2025)