Build vs. Buy vs. Assemble: A Decision Framework for Engineering Leaders Past $20M ARR

Why the binary framing is misleading

"Build vs. buy" is the language procurement and finance use, because the two options map cleanly to capex versus opex, internal capacity versus external spend, custom versus off-the-shelf. Engineering leaders who accept that framing inherit a debate that has already lost most of its useful nuance.

The reality on the ground is that almost every modern platform decision past meaningful scale is a hybrid. The CRM is bought, but the lead-routing logic is built. The ecommerce platform is bought, but the merchandising rules are built. The payment processor is bought, but the fraud rules are built. The LLM API is bought, but the prompt orchestration and safety layer is built. In each case, the commercial product handles the commodity work; the differentiated logic, the part the business actually competes on, sits in code the team owns.

This third option deserves its own name. Call it assemble: buy the commodity infrastructure, build the differentiated logic, and treat the seam between them as a first-class architectural surface, not an afterthought.

The four dimensions

Every build / buy / assemble decision should be scored on the same four dimensions. None of them is dispositive on its own; the pattern across the four is what matters.

1. Differentiation

Does this capability differentiate the business in the market, or is it table stakes? A capability that customers buy from you instead of from a competitor is differentiated. A capability customers expect any vendor to have is not.

• Heavy differentiation → lean toward build (or own the assembled differentiated layer).
• Pure commodity → lean toward buy.
• Most cases → assemble. The commodity foundation is bought; the differentiation lives in the layer above.

2. Operational fit

How well does the bought version match how the business actually operates today, and how is it likely to operate at the next scale milestone? "Fit" is a richer question than feature checklists make it look. It includes data model, permissioning model, audit semantics, multi-entity behavior, internationalization, and the fifteen edge cases that only show up in week three of operating the system.

The honest answer to "how well does it fit" almost always requires a working prototype against real data, not a sales demo. Sales demos are designed to maximize fit perception; operational fit is what survives Q3.

3. Lock-in cost

Two questions: how hard is it to leave, and how does the leaving cost grow over time? Vendor lock-in is not inherently bad, almost every infrastructure decision creates some lock-in, but the trajectory matters. A decision that locks the business in proportionally to the value it delivers is fine. A decision whose lock-in cost grows faster than the value it delivers is a slow-motion problem.

The single most useful test is the departure rehearsal: write down what would have to be true to migrate off this vendor in eighteen months, and price the migration at today's data volume and at 3x today's data volume. If the second number is unacceptable, the lock-in is real.

4. Total cost of ownership at scale

Bought systems have a cost surface that grows on three vectors at once: license / per-seat fees, the integration / data-pipeline tax to keep the system in sync with everything else, and the ops cost of running the bought system inside an organization that the vendor did not design for. None of these is captured cleanly in a procurement RFP, which is why the bought option's total cost of ownership at year three is almost always higher than what was modeled at procurement time.

Built systems have a different cost surface: the team to build it, the team to maintain it, and the opportunity cost of that team not building something else. Built systems also have a survival cost, if the team that built the system attrites, the organization can find itself owning a system nobody knows. Account for it.

The decision matrix

Score each option against each dimension on a 1-5 scale. The pattern that emerges should suggest the path:

• Buy wins decisively when the capability is commodity, operational fit is high, lock-in is acceptable, and TCO is competitive. Rare for capabilities that touch the differentiated edge of the business.
• Build wins decisively when the capability is heavily differentiated, no buy option fits operationally, lock-in for any buy option is unacceptable, and the TCO of building is outweighed by the differentiation premium. Rarer than engineering teams want to admit.
• Assemble wins when the capability has a commodity layer and a differentiated layer, where the commodity layer scores well on buy and the differentiated layer scores well on build. This is the answer for the majority of growth-stage platform decisions.

Failure modes by path

Each path has signature failure modes worth naming explicitly so leaders can plan around them.

Build failures

• The team that built it leaves. Single-person knowledge concentration is the most common build failure, and the hardest to detect early.
• The capability succeeds and then has to scale. The version 1 build often cannot survive 10x. Plan the next version into the original budget, not the next quarter's.
• The build outlasts the original requirements. Built systems acquire scope, and scope acquired without architectural attention turns the system into the platform it was supposed to integrate with.

Buy failures

• The demo is not the system. Sales demos are tuned. Operational reality reveals the gaps in week three. Always pilot against real data and real edge cases before committing.
• The vendor's roadmap diverges from yours. A vendor whose product strategy is moving away from your use case is a vendor you will need to leave. Read the roadmap deliberately before signing.
• The integration tax compounds. Bought systems do not integrate themselves. The fully-loaded cost of keeping a bought system in sync with the rest of the stack is usually 15-30% of the license cost, recurring.

Assemble failures

• The seam is treated as a procurement problem. The integration layer between the bought platform and the built differentiator is an architectural surface, not an RFP line item. Treating it as the latter is the most common assemble failure we see.
• Ownership of the seam is unclear. The bought vendor will not own it. The build team will not own it unless explicitly tasked. Ownership of integration code is the single most-skipped step in assemble architecture.
• Upgrades break the seam. Vendor upgrades change behavior at the integration boundary. If the team is not actively monitoring vendor release notes for breaking changes, the seam will fail at the worst possible time.

Contract mechanics that protect the buy decision

If the path is buy or assemble, the contract is where most of the protection lives. A few clauses are non-negotiable past meaningful scale:

• Data export and portability. The vendor must be contractually obligated to deliver a complete, schema-documented data export within a defined number of days, in a defined format, at no incremental cost. Without this, lock-in is whatever the vendor says it is.
• API rate-limit floors. Vendors raise rate limits as customers grow, often without notice and sometimes at additional cost. A floor in the contract, in writing, is the only protection.
• Roadmap influence proportional to spend. Past a meaningful spend threshold, the contract should grant a defined number of feature requests, advance notice on deprecations, and a named escalation path. None of this is automatic.
• Service-level commitments that match the criticality. A commodity SaaS with a 99.5% SLA is fine for non-critical use; for systems revenue depends on, the SLA needs to match the criticality. The vendor's standard SLA is rarely it.
• The exit clause. Most procurement focuses on the start of the relationship. The clause that determines whether the relationship ends well is the exit clause: notice period, transition assistance, data hand-back, and the vendor's obligation to keep the system running through the transition.

What a leader can do this week

Three concrete moves:

1. Reframe one in-flight build-vs-buy decision as a build / buy / assemble decision. Walk it through the four dimensions explicitly. The exercise alone often reveals which path is right.

2. Run a departure rehearsal on the largest existing vendor. Price what it would take to leave. The number is itself a useful asset for the next renewal conversation.

3. Audit the seam ownership. For every assemble pattern in production today, name the team that owns the integration code. If no team is named, that is the next thing to fix.

If you would like a second opinion on a specific decision in flight, the Software Delivery Architecture practice runs these exercises with growth-stage engineering teams as a focused two- to three-week engagement.