Shadow IT Was Never a Building Problem. It's a Visibility Problem.

Most leaders treat shadow IT as a building problem—employees making unauthorized tools—and respond by trying to stop the building. That’s aiming at the wrong target. The building isn’t the problem; the building is going to happen regardless, because the people closest to a workflow will always find a way to make the work go faster. The problem is that the building happens in the dark: ungoverned, unlogged, invisible to the leadership that’s accountable for it. Shadow IT isn’t dangerous because employees build. It’s dangerous because no one can see what they built. Reframe the whole debate from “stop the building” to “make the building visible,” and the strategy that follows is the opposite of the one most companies are running.

The instinct to clamp down is understandable and completely backwards. Prohibition doesn’t reduce shadow IT—it just removes the last bit of visibility leadership had.

TL;DR

• Shadow IT is building that leadership can’t see—not building itself. The danger isn’t that an employee made a tool; it’s that no one can audit, govern, or inherit it.
• Leaders consistently misdiagnose it as a building problem and try to stop the building, which drives the same activity further underground where it’s even less visible.
• The building is structural, not a discipline failure: Gartner’s research shows a large and growing share of technology is now created by people outside the formal IT org, and that share is rising, not falling.
• “SaaS discovery” tools inventory the logos employees signed up for, but knowing a tool exists is not the same as seeing what flows through it—who built it, what data it touches, who has access.
• Real org-wide visibility means being able to answer cross-cutting questions—who built what, touching which data, for whom—as a query, not a quarter-long audit.
• Visibility can’t be bolted on after the sprawl; it has to be a property of the foundation the building lands on, the same way a database is observable because it was designed to be.
• The winning move is to make building land on one governed substrate, so that distributing the building and seeing across it stop being opposites.

Why do leaders keep trying to stop the building?

Because the building is the part they can see, and the invisibility is the part they can’t. When a finance analyst stands up a tracker in a spreadsheet, or an ops lead wires three SaaS tools together with an automation, the visible artifact is the thing they made. So that’s what leadership reacts to: a new tool appeared without approval, therefore the fix is to prevent new tools from appearing without approval. Block the signup. Lock down the credit card. Add the app to the deny list.

This treats a symptom as the disease. The reason an employee builds outside the sanctioned path is almost never rebellion—it’s that the sanctioned path is a six-month queue and the work is due Friday. The drive to build is a permanent feature of any organization with more problems than engineers, which is every organization. You can no more stop it than you can stop people from using their phones for work. Prohibition doesn’t remove the demand; it removes the demand from view.

And that’s the trap. Every control that makes building harder doesn’t make it stop—it makes it quieter. The analyst doesn’t file a ticket and wait; they build the same spreadsheet, just somewhere IT will never find it. The org that “cracked down on shadow IT” usually just lost the last thread of visibility it had. The activity is identical. The darkness is deeper. That’s why banning shadow IT backfires: the prohibition trades the visible problem for an invisible one.

Why is shadow IT a structural reality, not a discipline failure?

Because the supply of people who can build has permanently outgrown the supply of professional engineers—and that gap is the whole story. There will never be enough engineers in the central org to serve every team’s every need, so the people closest to each problem build for themselves. This isn’t new and it isn’t going away. Gartner’s research on “business technologists”—employees outside the IT department who create technology and analytics capabilities—found that a large and rising share of the workforce now builds technology outside of IT, with funding for those purchases increasingly controlled outside the IT budget too.

Read that as a trend line, not a snapshot. The share of building that happens outside IT has been climbing for a decade and every force points the same direction: more capable tools, more pressure to move fast, more problems per available engineer. A strategy premised on bending that line back down is fighting gravity.

So the honest framing for any leadership team is this: assume the building will happen. Assume a meaningful and growing fraction of your operational software will be created by people who don’t report to your CIO. The only real decision left is whether that building lands somewhere you can see it, or somewhere you can’t. “Stop it” was never on the menu. “See it” is.

What does “make the building visible” actually require?

It requires answering questions that cut across what people build—not just knowing that a tool exists. A useful test: can leadership answer these as a query rather than a quarter-long audit?

• Who built this tool, and who inherits it when they leave?
• What data does it collect, and where does that data go?
• Which internal tools touch the billing system, and who approved that access?
• How many critical workflows depend on one person’s untracked build?

In a shadow-IT environment, every one of these takes a consulting engagement to answer—if it can be answered at all. They’re the same kind of cross-tool questions a fragmented org can’t answer across its systems: each one cuts across what people built instead of living inside a single tool. That’s the cost that doesn’t show up on any invoice: the org becomes illegible to itself, and illegibility makes every governance question, every security review, every audit slower and more expensive.

This is also why the popular “fix” falls short. SaaS-discovery and shadow-IT-detection tools are good at one thing: finding the logos. They scan expense reports and network traffic and hand you a list of the apps employees signed up for. That’s genuinely useful for the spend conversation. But a list of logos is a directory, not visibility. It tells you a tool exists; it tells you nothing about who built it, what data flows through it, or how it connects to everything else. Discovering shadow IT after the fact is a permanent game of catch-up against a thing designed, by default, not to be seen.

Stop the building vs. make it visible

The two strategies aren’t just different tactics—they point in opposite directions and produce opposite outcomes.

	”Stop the building” (prohibition)	“Make it visible” (governance)
Core assumption	Building outside IT is the problem	Invisible building is the problem
Response to demand	Block, deny-list, lock down	Channel onto a governed path
Effect on the activity	Drives it underground, unchanged	Surfaces it where leadership can see
What leadership ends up with	Less visibility than before	A queryable map of who built what
Effect on speed	Slower—work routes around the block	Faster—building is sanctioned, not hidden
Where the data lives	Scattered, undiscoverable	A shared, observable foundation
Scales as the org grows?	No—the gap widens	Yes—new builds inherit visibility

The left column describes what most organizations are doing right now, and it’s losing on every row. The right column isn’t “looser governance.” It’s more governance—just aimed at visibility instead of prohibition. The shift in framing is the entire move: you stop trying to prevent the building and start insisting it land somewhere you can see.

Why can’t you just bolt visibility on afterward?

Because you cannot observe, after the fact, a hundred things that were each designed not to be observed together. This is the part leaders consistently underestimate. They picture visibility as a layer you add—a dashboard, a discovery scan, an integration project that finally connects everything. But every tool an employee builds in the shadow-IT pattern is its own island: its own data store, its own access model, its own idea of what to log and what to expose. Stitching a map across a hundred islands that were never meant to connect is a permanent, losing maintenance burden.

Visibility has to be a property of the foundation, not a layer on top. Think about why a database is observable: not because someone bolted a monitoring tool onto it, but because it was built to be queried—logging, access control, and structure are part of what it is. Org-wide visibility works the same way. If everything people build lands on a common, governed substrate—shared identity, shared data layer, shared logs—then observability isn’t reconstructed after the sprawl. It exists by construction, because nothing was ever an island in the first place.

That’s the real reframe. The shadow-IT problem dissolves not when you stop the building, but when the building has nowhere dark to land. The deeper version of this argument—distributing the building while keeping leadership’s view intact—is laid out in what the winning org looks like, and the cost of not having that view is the subject of the real cost of SaaS sprawl.

What makes “visible by construction” finally practical

For most of computing history, “make everyone build on one governed foundation” was a fantasy, because building anything real required engineers—and engineers are precisely the bottleneck that creates shadow IT in the first place. You can’t tell the finance analyst to build on the sanctioned stack if building on the sanctioned stack requires a six-month engineering project. So they don’t. They open a spreadsheet, and the darkness wins.

That constraint is what changed. A new category of AI tool—the product agent—lets someone describe an application in plain language and get back a real, deployed full-stack app: backend, database, authentication, frontend, and deployment, not a prototype. Today the most advanced one is Remy. You describe what you need; it drafts a plain-language plan; that plan compiles into a working app with real server-side auth and roles, built-in request logs, and queryable analytics, running at a live URL. The plan stays the source of truth, so changing the app means editing the plan and recompiling—not hand-maintaining hidden code.

Here’s why that resolves the visibility problem specifically. Because a product agent compiles every app onto the same governed stack, the tools your teams build aren’t a hundred new dark islands—they share identity, data, and logs from the first line. The building is visible by construction. There’s no after-the-fact discovery scan, because there was never a shadow to discover: the analyst’s tracker and the support lead’s dashboard both ran through the same compiler onto the same foundation, so leadership has one place to look, by default. The cross-org observability layer every company will eventually want—the thing that answers “who built what, touching which data, for whom”—becomes buildable precisely because the substrate was shared from the start. That layer isn’t a finished product today, and it’s worth being precise about that; it’s what a shared foundation makes possible, not a feature shipping now.

The honest boundary: this is early. Product agents are in open alpha, and enterprise needs like SSO are still on the way, so the visibility story today is real server-side auth, roles, and agent-readable logs rather than a full enterprise identity suite. The winning org doesn’t wait for the category to finish maturing. It changes its operating model now—stop trying to stop the building, start insisting the building lands on something it can see—so that when the tooling fully arrives, the company is already shaped to use it.

FAQ

What is shadow IT, really? Shadow IT is technology—apps, tools, automations—built or adopted by employees without the IT department’s knowledge or governance. The defining feature isn’t that employees made it; it’s that leadership has no visibility into what it is, what data it touches, or who controls it.

Why is shadow IT a problem if it gets work done? The work getting done is the upside. The problem is invisibility: ungoverned tools create data, access, and dependency risks no one can see or audit, and the organization loses the ability to answer basic questions about how it actually operates.

Why doesn’t banning shadow IT work? Because the demand to build is structural—there are always more problems than engineers—so prohibition doesn’t remove the activity, it just pushes it further out of view. A crackdown usually leaves leadership with less visibility than it had before, not more.

Don’t SaaS-discovery tools solve shadow IT? They solve the discovery-and-spend part: finding which apps employees signed up for. But a list of logos isn’t visibility. It doesn’t tell you who built a tool, what data flows through it, or how it connects to everything else—which is the part that actually matters for governance.

What’s the difference between stopping shadow IT and making it visible? Stopping it tries to prevent employees from building outside IT, which drives the activity underground. Making it visible accepts that the building will happen and channels it onto a governed foundation, so leadership can see and query everything that gets built.

Why can’t visibility just be added after the fact? Because tools built in the shadow-IT pattern are designed as isolated islands, and reconstructing a map across them is a permanent losing battle. Visibility has to be a property of the foundation everything is built on, not a layer bolted on after the sprawl.

Where should a leadership team start? Stop framing shadow IT as a building problem to be suppressed, and start treating it as a visibility problem to be solved. Practically, that means giving people a sanctioned, governed foundation to build on—one where new tools are visible by construction—rather than a deny-list to route around.

The bottom line

Shadow IT was never about employees building things. It was about building that leadership couldn’t see. Every strategy aimed at stopping the building loses, because the building is structural and prohibition just drives it into deeper shadow. The strategy that wins flips the frame: assume the building will happen, and make sure it lands somewhere visible. That visibility can’t be bolted on after the sprawl—it has to be a property of the foundation the building runs on. A product agent that compiles every app onto one governed stack delivers exactly that: building that’s visible by construction, because nothing was ever a dark island to begin with.

If you want to see what building visible-by-construction looks like in practice, explore Remy →. For the operating-model argument behind it, read what the winning org looks like.