Why more AI-powered output doesn’t automatically mean more business value.
Apparently, we’re all developers now. Or at least we’re all people who can produce a working application and then discover how many things “working” can mean.
A few years ago, a custom marketing tool meant involving a developer, finding an existing product or persuading several no-code tools to cooperate. Today, I can describe a problem to an AI coding assistant and get much further before needing help.
I like this more than is probably sensible. I build tools, experiment with automation and connect AI assistants to marketing data. When an existing product is missing a connection or cannot quite handle the task, I have more options than I used to.
A frustrating spreadsheet can quickly become an application with a name, a dashboard and ambitions.
Before I get attached to the application, I try to ask what it improves. AI has made it easier to produce output. Business value still depends on what happens when someone uses it.
We’ve been here before. Just with fewer AI agents.
I was already connecting marketing systems through Airtable, webhooks and automation. A webhook sends information when something happens, such as a page being published. No-code tools let you connect those events without writing the integration yourself.
I wrote about building an AI-ready content library with Umbraco, Zapier and Airtable, and presented the approach at Umbraco Kalaset in Stockholm. The aim was to make website content available as structured data, kept in sync and usable for content work and analysis.
Having the content in one place meant we could query it for outdated references or gaps worth reviewing.
Now I can go beyond connecting existing products and build more of the system myself. That opens possibilities where a missing integration or an awkward limitation previously stopped the experiment.
I still need to know what problem I am solving, whether I have the right data and who will use the result. The coding assistant can help, but I have to decide whether the work deserves our attention.
More output can create the illusion of progress
A working prototype is satisfying. You can open it, click something and show another person. It is much easier to demonstrate than “we finally agreed what a qualified lead means”.
That makes it tempting to treat the prototype as evidence of progress. I find it useful to separate three things:
- Output: We built an AI-powered reporting tool.
- Outcome: The team spends less time preparing its weekly report.
- Impact: The team uses that time to improve campaigns, or makes better budget decisions, with benefits that justify running the tool.
The first can be demonstrated in a screen share. The others need evidence from actual use.
Imagine the tool assembles a report quickly, but someone then checks every figure, corrects the summary and recreates the chart in the old template. We have moved work around. Whether we have saved any remains an open question.
The comparison should include preparation, review and rework on both sides. Otherwise, we give the new workflow credit for the easy part and quietly leave the difficult part out of the calculation.
Experiments can still be worthwhile without becoming team tools. Learning how to connect a data source may be the whole point. Fewer errors or a less frustrating working day can count, too. I just want to be clear about which benefit I am claiming and what I have actually checked.
Marketing should recognise this problem
We already have plenty of experience with impressive output that needs a closer look.
More leads can mean more irrelevant enquiries for sales to sort through. More traffic can bring visitors who were never likely to buy. A growing content calendar can consume the time we needed to improve the pages that already influence a buying decision.
In lead generation, a campaign can produce fewer leads and better pipeline if it reaches the right people. A cheap lead becomes rather less cheap if sales spends time establishing that the person was only looking for a free template.
As marketers, we’ve spent years explaining why activity metrics aren’t the same as business results. We probably shouldn’t forget that lesson just because the activity now involves AI.
Counting agents, automations or tools tells us what we have introduced. I would rather know whether they helped us choose a campaign to change, gave sales more useful context or removed a recurring task. Otherwise, we risk creating a new set of activity metrics with a more impressive demo.
Sometimes the problem isn’t a missing tool
Consider a hypothetical B2B marketing team struggling with reporting. Campaign data lives in one system, lead records in the CRM, and the weekly pipeline discussion regularly ends with disagreement about the numbers.
An AI-powered reporting interface sounds attractive. It could pull the information together and let people ask questions without exporting another spreadsheet.
But suppose marketing and sales use different definitions of a qualified lead. Some records lack campaign information. Lifecycle stages are updated inconsistently, and nobody owns the rules for correcting them.
A new interface could make those records easier to access while leaving the disagreements intact. It might even give an uncertain answer more authority by presenting it confidently in a clean chart.
The useful first work may be agreeing definitions, fixing a field mapping or deciding who maintains the data. That can happen inside the existing systems.
A new tool might help expose the inconsistencies, too, or give the team a practical way to flag records that need correcting. And if the data is trustworthy but there is no workable way to connect it, building the interface could be exactly the right response.
An existing system may be inadequate, however much effort we have put into it. Understanding the obstacle helps us decide whether to replace it, improve an integration or agree how people should use the CRM.
Building is cheaper. Complexity isn’t free.
Getting a useful prototype together can take much less effort with AI assistance. Owning the result involves work beyond that first build.
A data connection can fail. An input format changes. Someone needs access, someone else needs instructions, and the tool’s creator eventually takes a holiday.
That means thinking about maintenance, reliable integrations, documentation, security and ongoing costs. It also means adoption. If colleagues still need me beside them to interpret the output, there is more work to do before I can call it a shared solution.
The level of care should fit the job. A small browser tool for my own work needs a different assessment from an automation handling customer records for a whole team. Neither needs a committee by default.
I also have to consider what I will spend less time on while maintaining it. The next campaign, a neglected landing page or better sales follow-up may deserve that time more. A quick first build does not settle that comparison.
The question I try to ask before building something
I try to describe the problem without naming the application I want to create. “I need to investigate why this page lost traffic” gives me something clearer to work with than “I need an AI dashboard”.
My Page Evidence tool is a practical example. It brings search and analytics evidence into content investigations, with an MCP connection that lets an AI assistant request the data. I built it to inspect what changed before deciding what to edit. I still have to assess whether it helps me make that decision.
Before expanding a solution, I want to know whether an existing report or integration can handle the task, and whether the necessary data is available and trustworthy. I also need to know who will use it and who will maintain it.
I want something concrete to compare afterwards: preparation time, corrections needed or whether the result helps me choose a next action. My Search Console backlog workflow connects evidence to a specific task and a later review, so I can follow the work beyond the report.
For a small experiment, a short note may be enough to give me that comparison.
Build things. Just remember why.
I’m going to keep building with AI, including solutions to small problems that never justified asking a developer to solve them.
I suspect the ability to produce a tool will become less distinctive as more people gain access to these capabilities. Knowing which problem deserves attention, how the solution fits the work and whether it helped may become more valuable.
My work is still marketing: reaching the right people, helping them understand the offer and giving sales something useful to follow up on. Data and technology give me more ways to improve that work.
I will probably build a few things simply because I am curious. But when I call something a business improvement, I’d like to be able to explain what got better when someone used it.
Recommended next
More writing connected by category or shared topics.