This blog post is AI-Assisted Content: Written by humans with a helping hand.

Something happened in the last year or so that we didn’t see coming — at least not this fast.

People across our business started building things. Not mockups. Not wireframes. Not, “Hey, could someone on the dev team make this for me?” requests. Actual, working applications. Someone on our team built an entire web-based tool inside Claude Desktop — ran on CSVs, solved a real workflow problem and worked on the first try. No development background. No ticket submitted. Just a person with a problem and an AI that could help them solve it.

And honestly? It was impressive.

This is happening everywhere right now. Analysts are building internal dashboards. Project managers are spinning up tracking tools. People who’ve never written a line of code are producing functional apps over a lunch break. The barrier between “I have an idea” and “I have a working prototype” has essentially disappeared.

If you’re in tech, if you love building things and watching people solve their own problems, this is an incredibly exciting time. The people doing this aren’t being reckless. They’re being resourceful. They’re finding friction in their day, and instead of filing a request and waiting six weeks, they’re fixing it themselves. That’s exactly the kind of energy you want in your organization.

So let’s be clear: This is not a “slow down” article. We are not here to be the fun police. But we need to talk about what happens next.

The Questions Nobody’s Answering

Every one of those impressive, resourceful, solve-it-over-lunch moments also carries a set of questions that nobody’s had time to answer yet.

Where does this app live? Who has access to it? What data is it touching? Is any of that data sensitive? Who maintains it when the person who built it moves on to something else? What happens when a dependency breaks or a CSV format changes? If it’s useful enough to share with the team, where does it get hosted? Who’s responsible for it?

These aren’t hypothetical concerns. Our IT team started getting hosting requests from people who aren’t developers, aren’t in development groups, and have never deployed anything before. They’d built something useful and wanted to share it. That’s a completely reasonable ask. But there was no framework to say yes.

So IT had to say no. And we all know what happens when you just keep saying no.

We’ve Seen This Movie Before

Anyone who’s been in data or IT long enough has lived through this cycle. When there’s no sanctioned path to get something done, people find their own way. They always have. It used to be rogue Excel files and unauthorized Airtable accounts. Before that, it was Access databases tucked away on shared drives that somehow became mission-critical. The tools change. The pattern doesn’t.

The difference now is that the tools are significantly more powerful. We’re not talking about a spreadsheet someone shared too broadly. We’re talking about applications — with interfaces, with data connections, with logic- being built and potentially hosted outside of any organizational oversight. If there’s no internal solution for hosting, people will find external ones. Personal accounts, free-tier platforms, wherever they can get something live. And once that starts, you’ve got data in places you don’t know about, dependencies you can’t track and a shadow IT problem that makes the Airtable era look quaint.

The Answer Isn’t No. The Answer Is “Here’s How.”

The instinct, especially from an IT and security standpoint, is to lock it down. Restrict the tools. Require approvals for everything. Make it hard enough that people stop trying.

That’s a mistake. Not because security doesn’t matter — it matters enormously — but because that approach has never worked. Not once, in the history of organizations and technology, has “just don’t do that” been a sustainable strategy. You don’t contain resourceful people by telling them to stop being resourceful. You give them a path that works for everyone.

That’s what we’re building right now. Not a set of restrictions — a framework. A way to say yes to the people who are building, while making sure what they build is discoverable, secure, maintainable and doesn’t end up as somebody’s personal side project running on an account IT has never heard of.

We’re calling it app governance — making sure the things people build are discoverable, secure, maintainable and don’t end up running on someone’s personal account that IT has never heard of.

What This Series Is About

Over the next several posts, we’re going to dig into the specific challenges we’re navigating and what we’re learning along the way. The repository sprawl — dozens of apps in different languages with no central inventory. The infrastructure burden on IT teams that didn’t sign up for this. The technical debt that accumulates at AI speed. The design and branding questions that surface when internal tools start getting shared externally. And ultimately, the playbook we’re putting together to make all of this sustainable.

We’re not writing this because we’ve figured it all out. We’re writing it because we think this is one of the most important operational challenges in tech right now, and almost nobody is talking about it openly. Everyone’s sharing the highlight reel — the amazing app someone built in an afternoon. Nobody’s talking about what happens the morning after.

We think it’s time to start.