Thirty-five percent of organizations replaced at least one major SaaS tool with a custom-built internal solution in the past year, according to Retool's 2026 Build vs. Buy Report. Sixty percent of those builds happened as shadow IT, outside official procurement, because the people doing the building were operations managers, finance leads, and technically capable marketers who stopped waiting for vendor roadmaps.

That statistic should make every CMO pause. The question is no longer whether your team has the capability to build internal tools. The question is whether building those tools is the highest-value use of their time.

The Seduction of the Build

AI coding assistants have collapsed the cost of building custom software. What once required a dedicated engineering team and a multi-sprint roadmap can now be prototyped in days. The same Retool survey found that 51% of builders have already shipped production software using AI, and about half of them report saving six or more hours per week. The math that once strongly favored buying has inverted for a growing category of internal tools.

Marketing teams feel this pull acutely. The patchwork of spreadsheets, shared docs, and half-fitting SaaS subscriptions that runs most marketing operations creates constant friction. Every campaign brief lives somewhere different. Approvals happen in email threads. Reporting means copy-pasting numbers on a Friday afternoon.

When a marketing ops lead realizes they can build a custom campaign tracker in an afternoon using no-code platforms like Softr or AI-assisted coding tools, the temptation is overwhelming.

The problem is that building software and doing marketing are fundamentally different activities, even when the software is for marketing.

The Hidden Cost Structure

Consider what happens when a marketing team builds a custom lead tracker, a content calendar, or an attribution dashboard. The initial build might take a few days. But then comes the maintenance: schema changes when a new data source is added, bug fixes when edge cases appear, feature requests from colleagues who want just one more field.

As Superblocks notes, one-off custom scripts created by developers may solve immediate problems but create long-term maintenance issues. These scripts often run without proper monitoring, error handling, or documentation.

The same dynamic applies to marketing-built tools, except marketing teams are even less equipped to handle the maintenance burden. Every hour spent debugging a custom dashboard is an hour not spent on campaign optimization, content strategy, or pipeline analysis.

I've seen this pattern repeatedly: a marketing ops lead builds an impressive internal tool, becomes the de facto owner of that tool, and gradually shifts from marketing work to software maintenance. The tool works. The marketing suffers.

When Building Makes Sense

This is not an argument against building. Some internal tools genuinely belong in-house. MindStudio's analysis of the vertical internal-tool market identifies the right target: the long tail of workflows that were too small to buy software for but too important to ignore. The workflows that never justified a full SaaS license. The shadow spreadsheets that surround your system of record.

The key is distinguishing between tools that automate a stable, well-understood process and tools that require ongoing judgment and iteration. A form that routes leads to the right sales rep based on territory? Build it. A dashboard that requires constant interpretation and adjustment as your attribution model evolves? Buy it, or better yet, use your existing platform's native capabilities.

Every custom solution adds another thread to untangle later.
Every custom solution adds another thread to untangle later.

The build-vs-buy calculus also depends on who does the building. Retool's data shows that 60% of shadow IT builds happen outside official procurement. That means marketing teams are building tools without IT oversight, without security review, without documentation standards. The tool might work beautifully for the person who built it. When that person leaves, the organization inherits a black box.

The Opportunity Cost Nobody Models

Here's the calculation I rarely see in build-vs-buy discussions: what would your marketing team accomplish if they spent those hours on marketing instead of software development?

Assume a senior marketing ops person spends ten hours per week maintaining custom internal tools. That's 520 hours per year. At a fully-loaded cost of $150 per hour, you're spending $78,000 annually on internal software maintenance. But the real cost isn't the salary. It's the campaigns not optimized, the attribution models not refined, the pipeline reviews not conducted.

Scott Brinker's observation that AI doesn't eliminate the constraints on innovation; it moves them from building things to making them matter applies directly here. The constraint on marketing effectiveness is rarely the absence of custom tools. It's the absence of strategic attention to the tools you already have.

A Framework for the Decision

Before your team builds another internal tool, run it through three filters.

First, is this a stable process or an evolving one? Stable processes with clear inputs and outputs are good candidates for custom builds. Evolving processes that require ongoing judgment should stay in flexible, vendor-supported platforms.

Second, who will maintain this tool when the builder moves on? If the answer is we'll figure it out, you're creating technical debt that will eventually land on someone's desk during a crisis.

Third, what is the opportunity cost? Calculate the hours your team will spend building and maintaining this tool over the next two years. Then ask: what marketing outcomes would those hours produce if applied to campaigns, content, or pipeline analysis?

The Real Question

The fusion of marketing and software development is real. Brinker has been documenting this convergence for years, and AI coding tools have accelerated it dramatically. Marketing teams can build software. The question is whether they should.

My answer: build sparingly, maintain ruthlessly, and never confuse the satisfaction of shipping a tool with the satisfaction of shipping revenue. The best marketing teams I work with have a clear rule: if a tool takes more than 10% of any team member's time to maintain, it either gets handed to IT, replaced with a vendor solution, or killed.

Model or it didn't happen. And the model should include the hours your team spends being software developers instead of marketers.