Build vs Buy is dead

Build vs Buy is dead. I haven't asked the question in a year.

For two decades, every enterprise leader has been trained to run the same playbook. A new capability shows up. You assemble a committee. You weigh feature parity against TCO. You run a vendor selection. You argue about whether to build it in-house. You produce a deck. You make a call.

I'm not running that play anymore. Neither is anyone serious I talk to. 

The capacity constraint is gone

The entire architecture of Build vs Buy rested on one assumption: building costs more than people think. Engineering hours were scarce. Internal projects ran late, missed scope, and rotted into maintenance debt. The math almost always said *buy*.

AI changed that math. Not by 20%. By an order of magnitude.

A competent GRC engineer with Claude Code can ship a workflow application in an afternoon that would have taken a team a quarter. A risk analyst can prototype an agent that would have required an RFP last year. The thing that was hard – turning intent into working software – is now the easy part.

When the constraint moves, the question has to move with it.

{{ banner-image }}

The new constraint is passion

Here is what I see in every serious enterprise I talk to: the technical people who can now build anything are choosing what to build. And they are not choosing based on ROI committees. They are choosing based on what excites them.

That is a completely different selection function. It treats the builder inside the enterprise as a craftsperson with finite enthusiasm, not a cost center with finite hours. And it is correct  because the work that gets the most creative energy is the work that compounds. The work that feels like overhead gets done once, badly, and then rots.

So the question is no longer *should we build or buy this?*

The question is:

- **What am I excited to build?**

- **How do I ship it fast?**

- **What do I build on? What do I build with?**

Build on. Build with. That is the frame.

The five layers nobody wants to think about

Every enterprise application, every single one, has the same anatomy underneath it:

1. **Access** to business data across dozens of systems

2. **Ingestion** of that data in formats that drift weekly

3. **Normalization** into a shape you can actually reason about

4. **Analysis** — sometimes

5. **Activation** — the workflow, the agent, the experience

Layers one through three are pure overhead. Nobody wakes up excited to maintain an integration to a corporate IAM platform whose API broke again at 2am. Layer four is sometimes interesting and sometimes plumbing, depending on the domain. Layer five – that is where you matter. That is the part that is actually *you*.

When you let a smart engineer vibe-build their own enterprise app, the dirty secret is that 80% of the time gets eaten by layers one to three. The first build feels great. Day two, day thirty, day ninety – the auth scheme rotates, the schema drifts, the rate limit moves, the vendor ships an update that nobody warned you about. The thing the builder was passionate about is now an integration maintenance job.

This is the trap. **AI sped up the first build. It did not speed up the long tail.**

The pattern is older than AI

This is not a new story. It is the same arc that played out with cloud, payments, deploys, and telephony.

- You used to rack your own servers. Then AWS. Now you build *on* AWS.

- You used to write card processors. Then Stripe. Now you build *on* Stripe.

- You used to manage your own deploys. Then Vercel and Cloudflare. Now you build *on* them.

- You used to run telephony stacks. Then Twilio. Now you build *on* Twilio.

Each wave does the same thing: it absorbs an undifferentiated heavy layer so builders can spend their creative energy on the differentiated one. The winners in each category were not trying to be everything. They were trying to be the most boring, reliable, invisible plumbing on the planet so that the interesting work could happen on top of them.

GRC is overdue for this layer. That is where I am spending my time.

What this means for GRC

A GRC engineer in a serious enterprise today has a choice.

They can spend their quarter wiring integrations to fifty corporate systems, maintaining UIs for stakeholders to click through standard actions, and writing connectors that nobody will thank them for. Or they can build the workflow that nobody else in the world is going to build for their organization, the one that captures how *their* business actually runs risk and compliance.

One of those is plumbing. The other is the reason they took the job.

If you are a technical GRC leader, the question you should be asking your team is not *should we build this control workflow or buy a tool?* It is:

> **What do you actually want to build? And what should we build on?**

That is the work that compounds. That is the work worth your people's time. Everything underneath it should be invisible, reliable, and somebody else's problem.

We are building Anecdotes to be that somebody else.