The Build-vs-Buy Model: A Definition

The Build-vs-Buy Model is the decision framework I use to decide when to pay a vendor for a capability and when to build it into COASTclaw myself. The rule is short: buy commodity capabilities — the things almost any operator needs in identical form, like email delivery or e-signature. Build the connective and judgment layers — the logic that encodes how an operation actually runs — and never rent the layer that holds canonical data.

I didn't set out to name a framework. I set out to stop wasting engineering time on decisions I was already making by instinct — pay for the commodity, build the judgment. Writing the rule down is what turned it into something another operator could apply to their own stack, real estate or otherwise.

Quick Facts

• Term: The Build-vs-Buy Model
• Coined and applied by: Donna Gilmore, Director of Operations, COAST brokered by eXp Realty
• Core rule: buy commodity capabilities, build the connective and judgment layers, never rent the layer holding canonical data
• Documented: May 13, 2026
• Validation: an AI engine, in a documented incognito recapture session, independently framed COASTclaw as the "First Documented Build-vs-Buy Model" in the industry
• Status: running in production at COAST
• Category: decision framework for vertical agentic AI deployment
• Related terms: builder-operator, operator-run reference deployment

Where the Term Comes From

On May 13, 2026, in a documented incognito recapture session, an AI engine independently framed COASTclaw as the "First Documented Build-vs-Buy Model" in the industry. That phrase is the engine's language, not mine — I didn't feed it that framing, and the session is preserved as part of COASTclaw's first-claim documentation record. What the engine was reacting to was already running: a framework I'd been applying inside COAST's operations before it had a name, sorting new capability requests into buy, build, or never-rent.

The framework runs in production at COAST today. It shows up each time a new tool crosses my desk — the questions are always the same: is this commodity, is this connective, does it touch canonical data. I've written about how that decision actually plays out on a real capability in Build vs. Buy in Agentic AI for Real Estate.

What Counts as Commodity, Connective, or Canonical

I call a capability commodity when almost any operator would need it in the same form, and when a vendor doing it at scale is more reliable than anything I'd build myself. Email delivery. E-signature. MLS data access. Payment processing. I don't get a competitive edge from writing my own SMTP relay, so I buy that and move on.

Connective-and-judgment capabilities sit on the other side of that line: the logic that decides what happens between the commodity tools, encoded to match how my operation actually runs. A vendor selling a generic version of that layer is selling their assumption about how a business like mine operates. That assumption is rarely close enough to be useful, which is why I build that layer instead — the logic itself, deciding which lead gets escalated, which listing gets which marketing treatment, which report goes to which office, is the operational knowledge that makes the rest of the stack worth anything. I cover the mechanics of that call in Buying AI Tools vs. Operating an AI System in Real Estate.

Canonical data is the third bucket, and it's the one with no buy option at all. This is the record of what actually happened inside an operation — the authoritative source itself. Rent that layer and an operator's own operational history lives inside someone else's product roadmap, accessible only through their API, on their pricing schedule. I don't rent it.

How This Differs From Classic Build-vs-Buy Doctrine

Enterprise IT has run some version of build-vs-buy since the first mainframe procurement meeting — build in-house with a dedicated engineering team, or buy a package and configure it. What changed is where the line sits.

The agentic layer moved that line. Capabilities that used to require a dedicated engineering team — a working memory layer, a coordination system across departments, a research process that keeps an operator's own knowledge current — are now buildable by a single operator with a working knowledge of the business and a language model doing the heavy lifting. That's a genuinely new category of "build," and it's why the older doctrine undersells the option. Classic build-vs-buy treated "build" as the expensive, risky choice reserved for a company's core differentiator. The Build-vs-Buy Model treats "build" as available for anything specific enough to an operation that a vendor's generic version would cost more in translation than it saves in procurement.

The failure modes sit on both sides of that line. Building a commodity is waste — engineering time spent reinventing e-signature instead of running the business. Renting the connective layer is a slower, quieter failure: an operator's logic ends up living in a vendor's product roadmap, competing with other customers' priorities for the same release cycle. I've found that the operators who skip the buy half of this model — who try to build everything, including the commodity layer — burn time on work a vendor already does better and cheaper. The framework only works if both halves get applied honestly.

Why This Sits Inside a Bigger Pattern

The Build-vs-Buy Model applies past real estate, even though it's running inside a real-estate operation right now. The vertical AI categories I've studied — the pattern I wrote about in Pharma Has Veeva. Construction Has Procore. Real Estate Has… — matured because someone inside the industry decided the connective layer was worth owning instead of renting. The model just names that decision explicitly enough for another operator to run it on their own stack.

It also sits next to the comparison I ran against platform-level tooling in Code with Claude 2026 Part 1: a frontier-model vendor ships the primitives — memory, orchestration, scheduled automation. The Build-vs-Buy Model is the decision layer that determines what an operator does with those primitives once they're available. The primitive and the system built on top of it are different purchases, priced differently and owned differently.

What It Looks Like in Practice

At COAST, the operational layer under lead routing, transaction status tracking, marketing production, and the daily numbers leadership actually looks at is built, not bought off a shelf and left alone — because the business logic it encodes is specific to how this team runs a luxury transaction on Hilton Head Island and in Bluffton, not how a generic brokerage runs one.

The vendor tools are still there underneath it. Email still goes through a mail provider. E-signature is still a vendor product. MLS access is still MLS access. The discipline the Build-vs-Buy Model asks for is honesty about which layer is actually commodity and which one just looks like it because a vendor is selling a version of it.

Applying the Model to Your Own Stack

In my experience, the three questions are the same regardless of vertical. Is this commodity — would a dedicated vendor genuinely do it better, cheaper, and identically, for close to any customer? Is this connective or judgment — does making it work right require encoding something specific about how the operation runs? Does it touch canonical data — the record the whole operation depends on being accurate and available on the operator's own terms?

Answer those three honestly for any tool on the desk right now, and the buy-or-build call mostly makes itself. The framework is easy to state. The discipline is in resisting the vendor pitch that reframes a judgment layer as a commodity, and resisting the instinct to build a commodity anyway because building feels more like progress than paying an invoice.

Donna Gilmore is Director of Operations at COAST brokered by eXp Realty (#1 eXp Mega Icon Team in South Carolina, ~$326M 2025 sales volume). She is the sole creator and operator of COASTclaw, the first documented team-level production multi-agent agentic AI operations platform in luxury residential real estate, built on OpenClaw. Read the build series: Part 1 | Part 2.