# Build the Brain. Buy the Infrastructure.

*Published 2026-09-30* | Author: chris-hart

> **tl;dr** Coding agents have made more of the growth stack practical to build in-house. McKinsey says 32 percent of organizations have already decided against at least one software purchase or feature because they could build it themselves. The implication is not to build everything. Build the profile, the weights, and the rules, and keep them somewhere you can read. Buy the identification, the connectors, the approval step, and the audit log, the infrastructure that has to stay reliable, connected, and auditable. And before you build, ask who else will need to trust what this system did.

*Coding agents have made more of the growth stack practical to build in-house. McKinsey says 32 percent of organizations have already decided against at least one software purchase or feature because they could build it themselves. The implication is not to build everything. You should own the judgment about who to target, what signals matter, and what should happen next. But you should buy the infrastructure that has to stay reliable, connected, and auditable.*

Nearly a third of organizations (32 percent) report that they decided against buying at least one software product or feature because they could build it in-house with agentic coding tools. Among the companies McKinsey classifies as high performers, nearly half say so.

That's from McKinsey's State of AI 2026 survey ([McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)).

If you sell software, that number should get your attention. I think it is mostly good news: buyers can own more of their intelligence and judgment, and vendors have to be clearer about the infrastructure customers should not have to maintain themselves.

## The CRO who built his own revenue operating system

The go-to-market version of that shift showed up in [The Signal's profile](https://www.thesignal.club/p/how-a-cro-uses-claude-code-to-run-a-100-person-revenue-org) of Tim Geisenheimer, a CRO who learned Claude Code eight months ago and has since built his own revenue operating system. He tests data providers against the same lead lists, logs each test with a hypothesis, cost, KPI, and verdict, and is building a likelihood-to-win model from his company's own closed deals. The author's takeaway after 18 months of consulting on similar builds was equally important: keep a human in the loop before anything is sent.

Kyle Norton, CRO of Owner.com, gave the cleanest framework I've seen for deciding what belongs on each side: "buy your infrastructure, build your intelligence." He asks five questions: How critical is uptime? How much customization do you need? Is it worth the engineering time? Is this proprietary intelligence? Does it create a real competitive advantage? ([SaaStr](https://www.saastr.com/how-owner-coms-cro-is-closing-2m-in-arr-per-rep-with-ai-5-things-you-can-steal-to-do-it-yourself), [Norton](https://www.therevenueleadershippodcast.com/p/dont-buy-your-gtm-brain)).

I agree these are the right questions to start with, but I want to add one question to the list, and then apply the whole thing to the product we build.

## What your growth team should build

Three parts of a growth stack are usually proprietary: your definition of a good account, the behaviors you care about, and the rules for what happens next. Those are also the parts customers should be able to inspect and change.

- **Your ideal customer profile.** Which companies, which roles, which stage. This is your judgment about your own buyers, and it changes every quarter.
- **Your signal weights.** Which behaviors matter for your product. A pricing page revisit means something different for a developer tool than for a payroll product, and the person who knows the difference is already on your team.
- **Your response rules.** When an account meets your criteria and shows a meaningful signal, what is allowed to happen next, on which channel, and who has to approve it.

If a vendor is guiding these three things and you cannot read them, change them, or take them with you when you leave, you have rented your intelligence from someone else. That's the part of the stack a growth team should own, whether those rules live in software you buy or code you maintain yourself.

## What your growth team should not build

Norton's uptime question is important here, and I'd extend it. Ask what happens to the pipeline if this breaks on a Tuesday afternoon.

- **Visitor identification.** Resolving an anonymous session to a company depends on licensed identity data and on matching that has to keep working as browsers, privacy settings, and data providers change. You will rent that data either way. The question is only whether you also want to maintain the matching.
- **Connectors.** The CRM, the outbound tool, the collaboration tool, and the product analytics each change their interfaces on their own schedule. Someone on your team then has to rebuild each time, and that's often the person who was hired to run revenue.
- **The approval step and the audit log.** This is the one I'd put at the top of the list, because it is the one internal builds tend to skip.

That last point deserves its own section.

## The step an internal build tends to skip

In the in-house agent builds I've seen, the builder is also often the operator. They trust their own judgment, so the approval step feels like friction, and the log feels like documentation for a reader who does not exist yet.

However, I would argue that the reader does exist. In May, Gartner predicted that by 2027, 40 percent of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents. Its diagnosis of the root cause is that enterprises treat agent governance as binary, either locked down or fully trusted, and it recommends classifying agents by autonomy level, with the "act with approval" level requiring clear approval workflows with audit trails ([Gartner](https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure)).

A CFO reviewing the growth team's tooling, a compliance lead answering a customer's data question, or a new Head of Growth inheriting the stack all need the same thing: a record of what the agent decided, who approved the rule it ran under, and what it did. Reconstructing that from a repository and a Slack history is possible. It is also the kind of work nobody budgets for until the question arrives.

So the question I would add to Norton's five is this:

Who else will need to trust what this system did?

If the answer includes finance, compliance, a customer, or the person who takes over the job next, the execution layer needs approvals and a durable audit trail. That does not mean you should buy the business rules themselves. It means the infrastructure that executes and records those rules has to be trustworthy from day one. It needs uptime, it needs to survive staff changes, and it needs to make what happened easy to reconstruct.

SIX PARTS OF A GROWTH STACK, TESTED AGAINST SIX QUESTIONS (interactive: select one of six parts of a growth stack to see what it is, which build-or-buy questions matter most, and where this article draws the line)
Select a part to see what it does, which build-or-buy questions matter most, and where this article draws the line.
Part of the stack | What it is | The questions that matter most | This article's take
1. Ideal customer profile | Which companies and roles are the best fit, and at what stage. It is your team's judgment about its own buyers and should change as the market and product change. | Is this core proprietary intelligence? Yes. Does it give you a competitive advantage? Yes. | BUILD. Own it. Keep it somewhere your team can read, change, and take with you.
2. Signal weights | Which buyer behaviors matter for your product, and how much. A repeat visit to your pricing page means something different for a developer tool than for a payroll product. | Is this core proprietary intelligence? Yes. How much customization does it need? A lot. | BUILD. Own it. Your team has the context to decide what matters.
3. Response rules | When an account meets your criteria and shows a meaningful signal, what is allowed to happen next, on which channel, and who approves it. | Is this core proprietary intelligence? Yes. Who else will need to trust what this system did? Finance and compliance, so the rules need to be readable. | BUILD. Own the rules. Execute them through infrastructure that records each action.
4. Visitor identification | Resolving an anonymous session to a company. Depends on licensed identity data and on matching that must keep working as browsers and data providers change. | How critical is uptime? High. How much customization does it usually need? Very little. Does owning the matching infrastructure usually create a competitive advantage? No. | BUY. You will rent the identity data either way. Do not also maintain the matching.
5. Connectors | The links to your CRM, outbound tool, collaboration tool, and product analytics. Each changes its interface on its own schedule. | How critical is uptime? High. Is maintaining them a good use of engineering time? Usually not. The maintenance never really ends. | BUY. Every API change creates maintenance work. It should not fall on the person hired to run revenue.
6. Approval step and audit log | A check before an action is taken, and a record of the trigger, the decision, who approved the rule, and what the system did. | Who else will need to trust what this system did? A CFO, a compliance lead, or your successor. How critical is uptime? High. | BUY. Treat it as infrastructure from day one. Internal builds often underinvest here because the first user is also the builder.
Framework: Kyle Norton's five build-versus-buy questions, plus one added here. The BUILD/BUY labels are my judgment, not survey findings.
Six parts of a growth stack, tested against six questions. Select a part to see which build-or-buy questions matter most and where this article draws the line. The placements are the author's judgment, not survey data.

## Where we drew the line inside Bryn

By Norton's framework, [Bryn](https://www.civic.com/bryn) is infrastructure around customer-owned intelligence. That is the line we chose.

Bryn identifies which companies are on your website and in your product, scores each account against the ideal customer profile your team defines, and, when the conditions your team set are met, runs the approved workflow. The workflow can execute automatically when the conditions match or pause for one-click approval before the final action.

The intelligence stays with the customer. Your profile, scoring weights, and response rules are readable and editable by your team. We built it that way because a scoring model the customer cannot read is the customer's own judgment sold back to them, and because the people who know which signals matter for a specific product are the people who sell it, not us.

The infrastructure is what we built: the identification, the connectors to the collaboration, CRM, outbound, and messaging systems most growth teams already run, the approval step, and one audit log that records the trigger, the score, the decision, and the action Bryn took on every run, exportable at any point.

One boundary matters here. Bryn can control what it initiates, but not what a connected system does after receiving the action. Bryn records what it initiated and why; the connected system keeps its own record of what happened next.

In practice, this changes two things for the people who run and pay for a growth stack. The buyer who revisits pricing on a Tuesday night can be scored and acted on under rules your team wrote while the signal is still fresh, rather than discovered in a weekly report. And when finance asks what the growth team's tooling actually did last quarter, the answer comes out of the audit log rather than out of a week of reconstruction.

## The decision in front of you

If your team is deciding this quarter what to build and what to buy, I'd start from Norton's five questions and add the sixth. Build the profile, the weights, and the rules, and keep them somewhere you can read. Buy the identification, the connectors, the approval step, and the audit log, or build them knowing you have taken on infrastructure, with the uptime and maintenance that word implies.

McKinsey's 32 percent is evidence that teams can build more than they used to. That shifts the value of software toward the parts customers should not have to maintain themselves: reliable identification, integrations, approvals, and auditability.

If you are working through where that line sits in your own stack, I would like to compare notes.

Source: https://www.civic.com/field-notes/build-the-brain-buy-the-infrastructure