Every CTO and VP of Engineering I work with eventually asks the same question: “Should we build this ourselves or buy a platform?” And every time, they want a simple answer. Build or buy. Pick one.
The real answer is almost always more nuanced than that. Looking at this decision across a dozen organizations—from $10M startups to $500M enterprises—a clear framework emerges that cuts through the noise. And the punchline, which I’ll save you the suspense on, is: buy the platform, build the last mile.
But let me show you how to get there systematically.
Why This Decision Is So Hard Right Now
The build-vs-buy decision has always existed in software. But AI makes it uniquely complicated for three reasons:
- The landscape changes every quarter. The tool you buy today might be obsolete in six months. The custom model you build today might be outperformed by an API call next quarter. This makes executives freeze—they’re afraid of committing to the wrong path.
- AI capabilities are deceptively easy to prototype. An engineer can build a demo in a weekend with an LLM API. That demo convinces leadership that building is easy. Then the team spends 8 months discovering that production AI is a completely different beast than prototype AI.
- The cost structures are unfamiliar. AI costs don’t look like traditional software costs. You’re paying for compute, inference, data labeling, model monitoring, and ongoing retraining. Most finance teams don’t have mental models for these line items yet.
These factors create decision paralysis. The framework below is designed to break through it.
The Four-Factor Decision Matrix
When I sit down with a C-suite team to work through build-vs-buy, I evaluate four factors. Each one gets a score, and the composite tells you which direction to lean.
Factor 1: Competitive Differentiation
The most important question: Is this AI capability a source of competitive advantage, or is it operational infrastructure?
If the AI you’re considering is something your competitors could also buy off the shelf—and it wouldn’t matter—then buy it. Customer support chatbots, document processing, basic analytics dashboards—these are commoditized capabilities. You gain nothing by building them from scratch.
But if the AI is core to your product’s value proposition or creates a data flywheel that competitors can’t replicate, that’s a build candidate. A recommendation engine trained on your proprietary transaction data. A pricing model calibrated to your specific market dynamics. A predictive system that gets better with every customer interaction.
Real example: A logistics company case I came across involved debating whether to build or buy route optimization AI. The answer: buy. Route optimization is a solved problem with mature vendors. But their customer demand prediction model—trained on 8 years of proprietary shipping data from a niche industry—that was a build. No vendor had data like theirs.
Factor 2: Data Sensitivity
How sensitive is the data the AI system needs to process?
This factor has become increasingly important. If your AI system needs access to PII, financial records, health data, or proprietary business intelligence, the bar for buying goes way up. You need to scrutinize the vendor’s data handling, storage, and processing practices. Some organizations in regulated industries (healthcare, finance, government) may find that the compliance overhead of vetting an external vendor exceeds the cost of building internally.
But don’t overweight this factor. Most modern AI platforms offer enterprise-grade data isolation, SOC 2 compliance, and on-premise deployment options. The question isn’t “is our data sensitive?” (it always is). The question is “are there vendors who can meet our specific compliance requirements?”
In one healthcare company case, the team was convinced they needed to build everything in-house because of HIPAA. After evaluating three platforms, two were found to be fully HIPAA-compliant with BAA agreements already in place. They saved 14 months of development time and $600K by buying instead of building.
Factor 3: Integration Complexity
How deeply does this AI need to integrate with your existing systems?
This is where the “last mile” concept becomes critical. Most AI platforms are designed to work out of the box for common use cases. But your business isn’t common. You have a specific ERP system, a specific CRM, a specific data warehouse, specific workflows that have evolved over years.
The integration layer—the connectors, the data transformations, the workflow triggers, the custom UI that sits on top of the platform—is almost always a build. And it’s often 40-60% of the total effort.
The mistake I see over and over: companies buy a platform expecting it to “just work,” budget nothing for integration, and then blame the platform when it doesn’t deliver. The platform was never the problem. The integration was.
Score this factor based on how many systems the AI needs to touch and how custom your workflows are. If the AI needs to pull from 2-3 standard systems (Salesforce, Slack, a modern data warehouse), integration is straightforward—lean buy. If it needs to touch 8 systems including legacy databases with custom schemas, you’re going to be building significant integration regardless, so factor that into your timeline.
Factor 4: Ongoing Maintenance & Evolution
What does it take to keep this AI system running and improving over time?
This is the factor that most teams underestimate, and it’s the one that has bankrupted more internal AI projects than any other. Building an AI system is a one-time cost. Maintaining an AI system is a permanent commitment.
When you build custom AI, you’re signing up for:
- Model monitoring: Watching for accuracy degradation, data drift, and edge cases
- Retraining pipelines: Regularly updating models as new data comes in and patterns shift
- Infrastructure management: Keeping GPU clusters, serving infrastructure, and data pipelines running
- Talent retention: Keeping the ML engineers who built the system (and who are being aggressively recruited by every company in your industry)
When you buy, the vendor handles most of this. Your team focuses on the business logic and the integration layer, not the model infrastructure. For most companies, especially those with teams under 500 people, the ongoing maintenance cost of custom AI is the deciding factor toward buy.
The Composite: Why “Buy the Platform, Build the Last Mile”
When applying this framework across cases I’ve studied, the pattern is remarkably consistent:
- Competitive differentiation usually points to build for 1-2 core capabilities and buy for everything else
- Data sensitivity is almost always manageable with the right vendor selection
- Integration complexity requires custom work regardless of build or buy
- Ongoing maintenance overwhelmingly favors buying the platform layer
The result: buy the platform that handles the hard, commoditized parts (model hosting, inference, monitoring, retraining) and build the last mile (your specific integrations, your custom workflows, your proprietary data pipelines, your unique business logic).
The Last Mile Framework in practice:
Buy: The AI platform, the model infrastructure, the monitoring tools, the base capabilities
Build: The data connectors to your systems, the business logic layer, the custom UI, the feedback loops that make the AI smarter with your specific data
Budget split: Typically 30-40% platform costs, 60-70% custom integration and last-mile development
Three Mistakes I See C-Suite Teams Make
Mistake 1: Treating the decision as binary. It’s not build OR buy. It’s almost always build AND buy. The question is which pieces fall into which bucket.
Mistake 2: Letting the demo fool you. A slick vendor demo or a weekend prototype can make either option look easy. Demand to see production deployments at similar scale. Ask for reference customers. Talk to teams who are 12 months post-deployment, not 2 weeks post-demo.
Mistake 3: Ignoring the opportunity cost. Every month your engineering team spends building AI infrastructure is a month they’re not building product features. For most companies, the highest-ROI use of engineering time is building the differentiated last mile on top of a purchased platform, not reinventing the platform itself.
How to Have This Conversation With Your Board
If you’re a CTO or VP of Engineering taking this decision to your board, here’s how I’d frame it:
- Start with the business capability, not the technology. “We need to reduce customer churn by 2 points” not “We need to build a machine learning pipeline.”
- Present the four-factor analysis. Show your scoring across differentiation, data sensitivity, integration, and maintenance. Be honest about where you land.
- Frame the recommendation as “buy the platform, build the last mile.” This resonates with boards because it balances speed-to-market (buy) with competitive protection (build the differentiating parts).
- Show the total cost of ownership for both options over 3 years. Include the hidden costs of build (hiring, retention, infrastructure, opportunity cost) and the hidden costs of buy (integration, customization, vendor dependency).
The companies that get this decision right don’t just save money. They ship faster, iterate faster, and focus their engineering talent on the work that actually creates competitive advantage. That’s the real ROI of a clear build-vs-buy framework—not the cost savings, but the focus it creates.