⚙️ I Talked to 100 GRC People This Week. Most Stopped Waiting for the Vendor.

This week in San Francisco I talked to about a hundred GRC people one-on-one, from fast-growing startups to household names. Most of them are building the last mile themselves.

A year ago, when a feature was missing, the answer was "the vendor should do that." This week it was "the vendor doesn't do that, and it's fine, I'll just do it myself." That's a different way of thinking about your domain, because you're a lot more empowered to make decisions.

Rebuilding the add-on

One team's GRC platform had a weak access review process, and the fix was a paid add-on module. So they pointed a vibe coding tool at the API and rebuilt the module themselves, pulling from the same source systems the platform was already pulling from. Instead of paying $15K for the module, they spent about $100 in tokens.

Tokens aren't the whole bill, obviously. Add a couple of days of someone's time to build and test it, and an hour or two a month to keep it running. For a small feature like this one, that's still a fraction of the add-on.

A platform sells to its ICP and extends in a logical, sequential way. Everything you ask for might not be what most of its customers ask for, so it will never be a one-to-one match for you.

If a platform doesn't cater to you, enough building blocks let you get the last mile yourself until their features catch up, which makes extensibility the way a platform keeps you. It's worth judging a platform on how easily you can extend it, as much as on its feature list.

Days without opening the UI

A lot of GRC leaders told me they go days without opening their platform's UI. They're working on GRC the whole time, through all the other ways in. Technically, it's the tool they should be using the most 🙃

When a UI bugs you, you open the coding harness and work through the four ways in: the CLI, the API, the MCP server and browser use. You get to work wherever suits you, and with OAuth everything you do still logs under your name.

Work outside the platform

One I've done myself a tonne of times: with the MCP, the API and browser use, an agent can go into almost any SaaS tool and pull the data, either as a screenshot or as the full population.

A script running in the background through the API or the CLI checks whether the control is working or failing. Then browser use uploads the finished evidence, as a PDF or similar, back into the GRC platform. I never open the UI myself.

The same works inside the tools engineers use. An agent can read the GitHub Actions and job automations already running in your environment and copy the practices they follow, like required reviews and pinned action versions, into your workflow. Then you sit down with someone on your team, or the engineers who own that tooling today, and agree an approach that won't disrupt anything.

Keep the last mile small

Last year I wrote that DIY automation breaks at enterprise scale. The people I talked to this week still hit the same walls: total cost of ownership, and needing one place where all the data lands and stays clean.

So the last mile means building small parts on top of a platform that keeps running the core, which means things are less likely to break and maintenance stays cheap. When the vendor ships the feature, you delete yours.

Before your next renewal

Run these against your platform.

Built something like this yourself? Hit reply and show me.

Ayoub