AI Build-Buy-Local Decision Framework
Choose SaaS, custom APIs, or local models from evidence and constraints
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 98%
Begin with a crawl-walk-run sequence rather than treating architecture as the first decision. Use an available SaaS platform to test the use case and prove that AI improves speed, quality, revenue, or cost. Once signal exists, evaluate three major constraints. First, if the capability is core to the product's value or competitive intellectual property, favor ownership and custom development. Second, if the workflow is narrow and repeatable, a small application built on an API can be much cheaper than broad business seats. Third, if confidential data cannot leave company boundaries, run a suitable open-source model locally. Customization is justified only when the benefit exceeds its development and maintenance burden or when an off-the-shelf solution cannot meet essential requirements.
Origin
Extracted from Marketing Against The Grain during a discussion among Mayur Gupta, Kieran Flanagan, and Kip Bodnar about enterprise AI architecture.
Core principles
- 01Start with the fastest credible experiment
- 02Own technology that is core to the product's differentiation
- 03Match infrastructure to confidentiality requirements
- 04Accept an 80 percent solution when edge cases do not justify custom work
- 05Build only after obtaining evidence of value
How to run it
- 1
Specify the outcome
Define the workflow, users, data, expected improvement, and metric that would demonstrate incrementality.
Pro tip Start with one narrow use case rather than an organization-wide platform mandate.
Watch out A vague goal such as adopting AI cannot produce a meaningful architecture decision.
- 2
Prove value with SaaS
Use an available cloud product or frontier-model seat to test whether the use case works in practice.
Pro tip Prefer the option that produces usable signal fastest.
Watch out Do not build infrastructure before confirming that model capability and user demand are adequate.
- 3
Test strategic importance
Determine whether the capability is core to the product offering or an operational support function.
Pro tip Own the layer that creates durable differentiation.
Watch out Building commodity support functions can create unnecessary maintenance.
- 4
Classify data sensitivity
Decide whether required information may enter a managed cloud environment or must remain within company boundaries.
Pro tip Separate sensitive and nonsensitive portions of the workflow where feasible.
Watch out Do not upload protected data merely because an experiment is convenient.
- 5
Compare delivery options
Compare broad SaaS seats, focused API applications, customized vendor layers, and locally hosted open-source models.
Pro tip Include ongoing operations and model changes in the cost comparison.
Watch out API usage can be cheaper, but custom software still carries engineering and support costs.
- 6
Choose the minimum sufficient architecture
Select the least complex option that satisfies strategic, economic, and security requirements, then reassess with real usage evidence.
Pro tip Let edge cases remain manual if the system solves the valuable majority of work.
Watch out Do not let a rare exception block an otherwise useful 80 percent solution.
In the wild
A financial-services company first tests document analysis with a managed AI product using nonsensitive samples. The experiment proves that employees can query years of research much faster. Because production documents contain confidential information, the company then deploys a local model and retrieval layer rather than sending the full repository to a public cloud service.
→ The organization validates value cheaply before investing in a privacy-compatible internal system.
Common mistakes
Building before finding signal
Custom development can consume substantial time before the team knows whether the model delivers useful results at scale.
Ignoring the core-IP test
Outsourcing a differentiating product capability may surrender control, while internally rebuilding a commodity feature wastes resources.
Designing around every edge case
Requiring complete coverage can make an economically valuable 80 percent solution appear inadequate.
Is it for you?
Best for
Leaders selecting between frontier-model seats, vendor products, custom API applications, and locally hosted open-source models.
Not ideal for
Organizations that have not yet defined a concrete use case or cannot measure whether an experiment creates incremental value.
From the transcript
“On one hand, I think it's a crawl walk and run.”
“One is is that core to your core product offering? If it is core to your core product offering, you want to own the IP,…”
“Or is it reasonable enough that it can solve 80% of your efficiency and then 20% are edge cases?”
From the episode
How a $1B+ Crypto Company Really Uses AI in Marketing