The Product Doesn't Do That — So I Built It in an Afternoon

For most of my career, "the product doesn't do that" was the end of a conversation.

You'd be in a meeting, ask the vendor for a report or a view or a single column of data that should obviously exist, and get the polite version of no. Maybe it was on the roadmap. Maybe it wasn't. Either way, you adjusted your expectations to fit the tool, filed a feature request into the void, and moved on.

That sentence doesn't end the conversation anymore. Now it starts a different one: okay, then I'll build it.

That quiet shift — from accepting the limits of a product to routing around them — is creating a category of work that most institutions have no real name for, let alone a policy on. "Citizen development" and end-user-computing policy come closest, and neither quite fits. I've started calling it shadow features.

What I mean by "shadow features"

We all know shadow IT: the unsanctioned tool, the department that bought its own project-management app, the lab server humming under someone's desk, the spreadsheet that quietly became a system of record. The defining move is users routing around IT because the official path is too slow or too rigid.

A shadow feature is the inverse.

It's IT routing around the vendor's roadmap. It runs on legitimate, licensed infrastructure. It uses the vendor's own documented API. Done right, nothing is smuggled, nothing is exfiltrated, no terms are violated. The platform does exactly what it's permitted to do.

What's ungoverned isn't the infrastructure. It's the behavior — a capability the product never shipped, conjured into existence by someone on the inside, living somewhere no one's looking.

Let me show you what I mean. I did exactly this a few weeks ago, and only realized afterward what I'd actually done.

The afternoon I built a feature my vendor didn't have

I've been running a GitHub Advanced Security (GHAS) pilot at a large private university. GHAS is GitHub's built-in security tooling — it scans code for vulnerabilities, catches leaked secrets, and surfaces alerts. A pilot like this isn't small money, and the whole point is to answer one question at the end: is this actually working? Do I recommend we buy it broadly or not?

To answer that, I needed reporting. Not a polished dashboard for a steering committee — just the instrument I needed to make a judgment call. This wasn't a sanctioned deliverable or a formal project. It was a leader trying to see clearly enough to decide.

Here's where it broke down. To know if the pilot is succeeding, you have to see alert state over time. How many are still open. How many got dismissed as false positives. How many were actually remediated. That breakdown is the whole story — a pile of "open" alerts that never moves means the pilot is generating noise, not security value. A healthy remediation trend means it's working.

Now, to be fair to GitHub: GHAS does ship a security overview dashboard and a CSV export. But the native views are built around default alerts and a fixed set of trend slices. They don't hand you an arbitrary, per-alert cut of open vs. dismissed-as-false-positive vs. remediated in a shape you can pivot yourself — and they quietly leave out things like third-party code-scanning alerts. The underlying data was all there in the API. The specific report I needed wasn't.

So I opened GitHub Copilot and vibe-coded a set of Python scripts that called the GitHub API and spat out exactly the CSV I wanted — the GHAS alert overview, sliced by state, for a given organization in our GitHub Enterprise Cloud environment. A few hours. One afternoon.

I'm a software engineer, so I want to be precise about what the AI did and didn't do here, because it matters. I could have written these scripts myself. The marvel wasn't "I can suddenly code." The marvel was speed. Left to my own devices, I'd have spent most of that afternoon writing boilerplate and bouncing through Stack Overflow tabs to remember the exact shape of a paginated API response. AI collapsed idea-to-working-tool into a fraction of that time. I went from "I wish I could see this" to "here's the CSV" before lunch was a memory.

Sit with the result for a second: a capability that did not exist in the product now existed. Built from the vendor's own API, on licensed infrastructure, by me, in an afternoon.

It's a small thing on its own — a one-off reporting script, not a system. But the move behind it isn't small, and higher ed is where it keeps showing up.

Why higher ed makes this sharper

None of this is unique to universities. But higher ed is unusually fertile ground for it.

It varies a lot by institution type, but across much of higher ed the conditions line up. Procurement is slow — the gap between "we need this" and "we're allowed to buy this" can run quarters or years, which is plenty of time to build the workaround. Development staff is thin, so the few capable engineers are exactly the people improvising tools to cover what the budget won't. Vendor roadmaps run on commercial timelines that don't care about your academic calendar. And there's a deep, genuinely admirable "just make it work" culture baked into campus IT.

Those are the precise conditions that breed shadow features. The frameworks to govern them haven't caught up. [NEEDS: a peer signal — do you know others doing this, or do you feel like the first to name it? One concrete data point lands the section.]

What I'd actually do about it

I'm not arguing for a ban. A ban just pushes this further into the dark, and the capability is too useful to lose.

A lightweight posture instead.

Name it. Give the category a word — shadow features — so people can disclose instead of hide. You can't govern what no one will admit exists.

Log it. Not a change-control gauntlet. A shared doc is enough: what it does, who built it, and what breaks if it stops working.

Make a lifecycle call. Most of these scripts are throwaway, and that's a perfectly good decision — as long as it's an actual decision and not a default. The one that matters is noticing the day a personal convenience turns into something other people depend on, and choosing, deliberately, what happens then.

For my GHAS script, the honest call is that it stays ad-hoc — reporting for a judgment I'm making myself, not a system anyone else runs. But I'm writing down what it does and how to rerun it, so the recommendation it feeds is at least reproducible by someone who isn't me.

So I'll put it to you, since I suspect I'm not alone: what's running in a venv on your team's laptops that's quietly become part of how the work gets done — and have you actually decided what it is, or just let it sit there?