In a June survey of about 1,000 U.S. workers across all industries, Software Finder found one in three said their company had rolled out an AI tool that people later largely stopped using. Only 6% thought their managers knew very accurately how often people actually used new AI tools.

So the tool gets built, launched and probably celebrated, and then it quietly fades. I'd guess the person who signed off on it is often the last one to find out.

Gartner expects the same thing at the big end. By 2027, they predict 40% of enterprises will demote or shut down AI agents they've already launched, because of gaps in how they were managed that only showed up after something went wrong. At a big company, that usually means an alert goes off and somebody's phone rings. At a DMO, I don't think anything rings. The project just goes quiet.

Launch day feels like the finish line

Here's what I mean. This is a made-up example, but I think a lot of you will recognize it.

A marketing director at a 12-person DMO gets the green light in the spring for an AI project. Their most tech-savvy coordinator builds most of it herself over a few weekends. There's an automation that pulls partner events into the monthly events calendar, and an assistant that drafts follow-up emails for the sales team. The first couple of months are exciting. The calendar that used to take two days now takes an afternoon.

Around month four, the partner portal changes how it labels event dates, and the calendar starts quietly putting a few events in the wrong month. No error, no alert. That same month the coordinator gets pulled onto a big festival, and a new salesperson starts who never hears the assistant exists. By month six the tool is still technically there, but the team has drifted back to doing the calendar by hand and pasting drafts into their own ChatGPT tabs.

Nobody ever decided to stop using it. The person who built it had a day job, and the day job won.

I'll admit this happens to me too, and I build this stuff for a living. I have a daily briefing that's supposed to land first thing every morning. A few weeks ago I renamed it, a purely cosmetic change, and for two days it showed up in the afternoon instead. Nothing told me. I only caught it because I read it every day. If the person who built it can miss that, imagine what a tool nobody's watching is quietly doing.

Why good builds go quiet

A study MMGY Travel Intelligence ran this spring for Mindtrip, Sabre and Sojern found only 26% of DMOs have a documented AI strategy. The barriers DMO leaders named most were bandwidth, technical expertise and budget, and all three come back after launch in four pretty normal ways.

The first is that nobody owns it after launch. During the project, it belongs to the project. After go-live it belongs to everyone, which in practice usually means no one.

The second is that the tools underneath it keep changing. AI models update all the time, and the platforms you connect to rename fields, change logins and retire features. An automation that worked perfectly in March can be quietly wrong by July.

Third, the people change. DMO teams are small, so when the one person who understood how something works moves on, there's often nobody left who can fix it. Destinations International heard a version of this in its workforce listening sessions, where CEOs admitted succession planning is usually reactive.

And fourth, there's no line for it in next year's budget. The build gets funded as a project. Keeping it running isn't a project, so year two shows up with no money or time set aside for upkeep.

None of these make noise. Usually what you see is a report nobody quite trusts anymore, or a tool nobody opens.

Everyone's a builder until something breaks

I love that building has gotten this accessible. I'm a huge fan of what I call simple SaaS, where you use AI to build your own tools, for yourself or a very small team. I think we're going to see a lot more of it, and I'd encourage it. If a tool only you use breaks, you notice, and you're the only one it slows down.

Something you spin up over a weekend for your whole organization is far different. That's where everything in this piece really matters, and where building it was never the hard part. The question I'd ask is who owns the problem when it breaks. Who notices the numbers look off, who figures out why, and who has time to fix it that week?

October gave us a good example. On October 21, PHP, the language behind WordPress, Drupal and probably a lot of destination websites, shipped emergency fixes for two critical security flaws that had been sitting there for over a decade. The same day, a popular open-source Python tool many AI apps use to connect to models had a poisoned update in its official downloads for a couple of hours, built to steal passwords and keys. Somebody had to hear about it, work out whether your site or tool was exposed, and patch it that week. If you bought from someone, that was their week. If you built it yourselves, it was yours, whether anyone saw the news or not.

Usually that's the person who built it, on top of the job they already have. You'd really want two people who understand it, so one vacation or one resignation doesn't stall the whole thing. On a 12-person team, that's a sixth of your staff. A lot of DMOs are smaller than that. Travel Oregon's survey of the state's tourism organizations found the average one has seven full-time employees, and at that size two people is closer to a third of the team.

That cost almost never shows up in the plan. When you buy from a company you trust, a big part of what you're paying for is everything that happens after launch. Someone fixes it when it breaks, patches it when an October 21 comes along, keeps it working when a model or a connected tool changes, and handles the ongoing maintenance you'd probably never think to budget for. And it's their full-time job, rather than something squeezed into someone's week on your team. Building can still make sense, especially when nothing out there fits what you need. I'd just go in honest about who's going to look after it.

What keeps one alive

The good news is none of this takes a big team, just a few small habits you decide on before launch.

1. Name an owner, and make it real. Even if a vendor handles the fixes, someone on your team should own how it's used. Pick the person who uses it most, give them an hour a week that's actually protected, and put it in their goals so it counts.

Gilad Berenstein, an AI investor and the founder of Brook Bay Capital, wrote something recently that explains why this matters. "A finished tool can be shared but the judgment earned while building it is harder to transfer." His piece makes the case for leaders getting hands-on with AI themselves, and I'd stretch it to whoever owns yours. If they're involved while it's being set up, rather than handed it at the end, they'll know what normal looks like and they'll notice when something isn't.

2. Budget for year two in year one. If you're buying, ask what support looks like after launch and make sure it's in the price. If you're building, put the upkeep hours in someone's actual workload. Either way, it should be in the plan before launch day.

3. Hold a 15-minute check-in every month. Ask whether it's still running, what broke or felt off, and what you'd add next. Fifteen minutes is enough to catch the wrong-month events in week one instead of month four.

4. Write down how it works in plain English. One page covering what it does, where it gets its information and who to call when it acts up. It takes an hour, and it saves you when someone leaves.

5. Start smaller than feels impressive. I'd take one workflow your team uses every week over five that looked great in the demo. Get one thing to stick, then add the next.

The question to ask before you sign anything

Whether you're buying a tool, hiring a consultant or building it yourselves, ask one question before you commit... "What happens in month seven?"

Then get specific, even if the builder is your own team.

• Who keeps an eye on it after launch, and how will we hear about it if something breaks?
• What happens when a tool it connects to changes or gets updated?
• If the person who championed it here leaves, who trains the next one?
• What did you do on October 21?

It sounds like a strange question, but a team that really looks after its software heard about the PHP and Python news that day and can tell you in a sentence what they checked.

If you've got a project that's gone a little quiet, I'd start by asking who owns it now. A lot of the time, that's most of the fix.

-Jason

We build AI tools for destination marketing teams at Swix AI. If any of this sounds familiar and you'd like to compare notes, I'm always happy to talk.

Credit where it's due. The forecast is from Gartner. The worker survey is Software Finder's (1,005 employed U.S. workers, June 2026). The DMO strategy figure comes from a study MMGY Travel Intelligence conducted for Mindtrip, Sabre and Sojern (release, April 2026 fieldwork, as reported by PhocusWire). Team size is from Travel Oregon's Destination Needs Survey, and the succession point from Destinations International. The line on judgment comes from Gilad Berenstein's AI Leadership Requires Earned Wisdom, which is worth a full read if you lead a team. The PHP details come from Wiz Research, and the Python details from BleepingComputer.