Build Last: A Procurement Rule for AI Governance Tools: Adopt First, Support What Can Be Sourced, Build Only When a Documented Search Has Failed

Mission fit and sunk effort justify nothing. The only thing that justifies building is a search that failed and got written down.

The Reflex

The sequence is familiar enough to recite. A governance gap appears during an audit. Nothing on the market fits exactly. Someone has built something adjacent before. A spreadsheet appears, then a script, then an internal app with two maintainers and no roadmap. Eighteen months later it's load-bearing for a compliance obligation and one maintainer has left.

Nobody made a bad decision. Each step was locally reasonable, and the aggregate is an unfunded dependency in a regulated control path. The rule I hold myself to: adopt first, support what can be legitimately sourced externally, build as a last resort. Strong on purpose, because the reflex it opposes is strong and the failure it prevents surfaces years after the decision that caused it.

The Three Gates

The rule is only useful as questions someone answers before the first commit.

Does it exist? Not "does a product solve this exactly," which is almost always no and is the wrong question. Does something solve 70%, where the rest is process rather than software? Most governance gaps are answered by an existing tool plus a decision nobody wants to make, and building lets us avoid the decision. Search commercial products, open-source projects, standards bodies with reference implementations, and the adjacent thing built for a neighboring problem. That last holds most of the missed answers.

Can we support it? A tool we can't operate isn't an answer. This gate asks about licensing that survives our use case, maintenance that doesn't rest on one upstream volunteer, data handling that meets our obligations, and an exit path. A dependency we can't leave is one we've mispriced. Supporting also means contributing: funding or patching the last 30% usually beats building 100%, and leaves the capability where someone else maintains it.

Does the gap survive contact? After the first two gates, restate it in one sentence. Often it has shrunk to something that isn't a software problem: a policy never written, a threshold nobody would set, a role missing from the org chart. Those don't close by building. Building on them produces a tool that encodes the unmade decision and makes it harder to revisit.

Mission Fit Justifies Nothing

Two arguments arrive here, and both need refusing plainly.

The first is mission fit. "This is core to what we do, so we should own it." Owning and building are different decisions, and the second doesn't follow from the first. A firm whose mission is legal judgment doesn't therefore write its own document management system. Core competence argues for controlling the interface and the data, not for authoring the implementation.

The second is sunk effort. "We've already put four months into this." Four months tells us about the past and nothing about the next four. It feels like it does, which is why this needs a rule rather than a judgment call in the moment.

Both are the kind of reasonable that survives a meeting, which is why the gates get answered in writing first.

Writing Down the Search

The gates are worth little alone. What makes the rule compound is the artifact: a record of what was searched, what was found, and why it didn't fit. Six months later someone hits the same gap from another direction, and without the record runs the same search badly and builds a second tool.

A usable record has four parts and fits on a page:

The gap, in one sentence, as stated before the search.
What was evaluated, including adjacent tools considered and set aside.
Why each failed a gate, naming which gate.
The date, because this expires.

That last part matters more than it looks: a build decision justified by a two-year-old search is justified by nothing.

We Run This On Ourselves

I'd rather state the awkward version than the flattering one. Every component in our portfolio exists because a capability was missing in real work and the search came up short. That's exactly the claim a founder makes too easily, so the rule applies hardest to us. The adopt-first test doesn't get easier because we already wrote the thing. Where an external standard or project can carry part of what we built, the right move is to adopt it and retire ours. Some of those calls are still open.

When Building Is Right

The rule isn't "never build." Building is last and entered deliberately, when the search failed on the record, the gap survived the third gate, and the build has an owner, a budget, and an end state. What it prevents is the other path, where we arrive at a custom internal dependency without ever deciding to.

Next time a governance gap appears, the first artifact shouldn't be a prototype. It should be the page saying what already exists.

Ready to know which capability gaps are real before building for them? Learn about PAICE for organizations or take an individual assessment to see it firsthand.

Build Last: A Procurement Rule for AI Governance Tools