Build and Buy

Don't choose between building or buying—do both strategically

Austin Hay
The ultimate guide to Martech

Build and Buy

"Build and buy as opposed to build versus buy. Build versus buy is a very narrowly constricting decision tree. If it's only build versus buy, then you've already made the decision that you can only do one or the other. Build and buy means that both of you can win." — Austin Hay

What It Is

Build and Buy reframes the classic "build vs. buy" technology decision from a binary choice into a complementary strategy. Instead of choosing between building custom software OR purchasing a third-party tool, the optimal approach is often to buy a tool that gets you 90% of the way and build the remaining 10% on top of it.

This mental model shifts the conversation from adversarial (engineering vs. procurement) to collaborative (how do we get the best outcome together?). It acknowledges that neither pure building nor pure buying is usually optimal—the right answer lies in strategic combination.

How It Works

The Old Model (Build vs. Buy):

  • Binary choice: either we build it ourselves OR we buy a vendor solution
  • Creates organizational conflict between engineering and operations
  • Forces suboptimal decisions when neither option is ideal
  • One side "wins" and one side "loses"

The New Model (Build and Buy):

  • Buy the third-party tool that solves the core problem
  • Build custom functionality on top for your unique needs
  • Create synergy between vendor capabilities and internal engineering
  • Both teams contribute to the optimal solution

The 90/10 Principle:

  • Buy the tool to get 90% of the way there
  • Build the cool, differentiating stuff with the other 10%
  • This is where velocity comes from—not reinventing commoditized infrastructure

How to Apply It

  1. Reframe the conversation — When you hear "should we build or buy this?", respond with: "What parts should we buy, and what parts should we build on top?"

  2. Map the problem surface — Identify which aspects of the problem are commoditized (good candidates to buy) vs. unique to your business (good candidates to build).

  3. Build a financial model — Compare the true cost of pure build, pure buy, and build-and-buy approaches. Include engineering time, maintenance, vendor costs, and time-to-value.

  4. Leverage vendor relationships — Large customers who build on top of vendor platforms often get accelerated support and influence on product roadmaps.

  5. Design for extensibility — When buying, choose tools with good APIs and extension points. When building, create hooks for potential future vendor integrations.

Example Application

Scenario: A company wants to build an A/B testing system.

Pure Build Argument: "This is core to our technology. We have engineering resources. We should build it ourselves."

Pure Buy Argument: "Split.io does this already. Let's just buy it."

Build and Buy Approach:

  • Buy Split.io (or similar) for core experimentation infrastructure
  • Build custom integrations connecting it to your data warehouse
  • Build proprietary analysis tools on top of the experiment data
  • Build custom UI components that match your internal workflows
  • Result: Faster time to value, lower total cost, more differentiation

The company saves months of infrastructure work while still creating unique competitive advantage in how they use experimentation.

When to Use It

  • Technology strategy discussions: Reframe any build-vs-buy debate
  • Vendor evaluations: Evaluate tools partly on their extensibility and API quality
  • Engineering planning: Allocate resources to high-value custom work, not infrastructure
  • Budget discussions: Build financial models that show the combined approach

Benefits of Build and Buy

  1. Faster time to value: Don't reinvent infrastructure that vendors have perfected
  2. Lower total cost: Engineering time goes to differentiation, not commodity features
  3. Better vendor relationships: Committed customers get better support
  4. Competitive advantage: Your custom layer becomes your moat
  5. Organizational harmony: Both engineering and operations contribute

Common Mistakes

  • Building commoditized infrastructure: Building your own CDP, data warehouse, or email system when vendors do it better
  • Buying without extending: Just implementing vanilla third-party tools without customization
  • Underestimating integration work: The "and" in Build and Buy requires integration effort
  • Ignoring vendor lock-in: Build your custom layer to be somewhat portable

Source

  • Guest: Austin Hay
  • Episode: "The ultimate guide to Martech"
  • Key Discussion: (01:07:52) Austin describes how Build and Buy creates consensus-driven solutions
  • YouTube: Watch on YouTube

Related Frameworks

  • Tools Solve Problems — The philosophy that tools exist to solve problems, not as ends in themselves
  • PPS Framework — How to understand the problem before reaching the Build and Buy decision
Back to Execution