Build AND Buy
Reframe build-vs-buy as build-and-buy: buy 90% off the shelf, build the 10% that differentiates.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 95%
Hay rejects the binary build-versus-buy decision as needlessly constricting and politically divisive. Instead he reframes every tooling decision as build AND buy: procure a third-party tool to get 90% of the way there, then build the differentiated 10% on top. This creates consensus, saves resources, and produces velocity because the vendor becomes invested in your success.
Origin
Austin Hay's framing, taught in his Reforge martech course and applied at Ramp and in consulting engagements.
Core principles
- 01Build-versus-buy is a narrow decision tree: choosing one already pits you against someone in the org.
- 02Build-and-buy is consensus-driven, so both camps can win.
- 03Buy the tool for 90% of the capability, build the differentiated 10% on top.
- 04Building on a vendor gives you mutual benefit: a committed vendor accelerates SDK changes and features for a large invested customer.
How to run it
- 1
Decompose the problem, not the decision
Instead of asking 'do we build or buy this?', break the problem into parts and ask of each: what can we buy, and what should we build?
Pro tip Use this framing out loud in meetings when someone proposes building an expensive tool in-house; it defuses the turf fight.
- 2
Buy the commodity 90%
Purchase the third-party tool that gets you most of the way there at the lowest possible cost, so your engineers do not rebuild solved infrastructure.
- 3
Build the differentiating 10% on top
Invest your freed-up engineering resources building the unique layer on top of the bought tool that gives you velocity and advantage.
- 4
Justify with a financial model
Build a financial model comparing full in-house build versus buy-plus-build-around, including operational efficiency and fixed and variable cost, to make the trade-off explicit to stakeholders.
Watch out Do not over-index on the future so far that you miss product-market fit or spend build time that should have gone to a key product feature.
In the wild
A consulting client (and separately Ramp) wanted to build their own A/B testing system in-house, arguing they had the engineering resources and it was core technology. Hay ran a financial model comparing building the entire system versus buying a third party (e.g. split.io) at lowest cost and spending resources building around it.
→ The model showed they could make more money, save money, and move faster by buying the third-party tool and investing their engineering effort building on top of it rather than from scratch.
Common mistakes
Framing it as build versus buy
Posing the choice as strictly build-or-buy forecloses the decision and creates an adversarial fight in the org, when the better outcome is almost always buying the commodity layer and building the differentiated layer on top.
Building solved infrastructure in-house
Rebuilding a commodity capability like A/B testing from scratch burns engineering resources that could differentiate the product, usually costing more and moving slower than buying and building around a vendor.
Is it for you?
Best for
Growth and martech leaders evaluating whether to build an internal tool or procure a SaaS vendor, especially when engineers argue for building.
Not ideal for
Truly core, differentiating technology where no adequate vendor exists, or trivial needs where buying alone fully suffices.
From the transcript
“so you buy the tool to get 90 of the way there and then you build the cool thing on top with the other ten…”
“build versus buy is a very narrowly uh constricting decision tree right if it's only build versus buy then you've already made the decision you…”
“the entire engagement was basically designing a financial model to show them that they could make a lot more money save money move faster if…”
From the episode
The ultimate guide to Martech
Austin Hay (Reforge, Ramp, Runway)