Phase 01
Strategize. Per use case, we recommend build, buy, or partner with rationale. We document why we did not pick the other options.
Methodology
Build / Buy / Partner.
The honest call per use case.
Category
MethodologyWhen we recommend it
Every use case in every Phase 01. The output of this framework is a single sentence per use case: "We recommend building this because X. We considered buying Y but rejected for reason Z."
What it is
The framework, what it covers, and the problem it addresses.
A decision framework applied per use case: build (custom development), buy (license an off-the-shelf product), or partner (work with a specialist firm or co-develop with a vendor). The decision is forced explicitly because the default tendency in AI engagements is to build, even when buying is faster and cheaper.
Why it matters
The reason this framework exists in the Rubix toolkit, and why omitting it is the wrong shortcut.
AI consulting has a structural bias toward building. Builders make money when they build. The Build/Buy/Partner discipline is what produces honest recommendations: sometimes the best answer is 'license this product from this vendor, do not engage us further.' Saving the client from a Phase 02 engagement they don't need is part of the value.
In the Kingdom and the GCC
Regional context. PDPL, SDAIA, Vision 2030, Saudization, and the operating realities that shape how this framework lands here.
In KSA and the GCC, the Build/Buy/Partner conversation has additional dimensions: data sovereignty (some buy options are excluded by KSA-resident inference requirements), Saudization (some build paths require capability-build investment), and procurement timing (some buy options ship in weeks, some build paths in quarters). The framework forces these constraints into the decision rather than discovering them late.
How Rubix applies it
The phases of the Rubix Way where this framework is operationalized, and what we do with it there.
Phase 02
Build. If we recommended buy or partner, Phase 02 is the procurement and integration work, not custom development.
Common pitfalls
The failure modes we have seen up close, written so the next engagement avoids them.
- 01
Building because the team is excited, not because the build is the best option. The framework's value is forcing the buy alternative to be considered seriously.
- 02
Buying because something looks like an off-the-shelf fit, without checking domain and sovereignty constraints. Many off-the-shelf AI tools fail KSA compliance.
- 03
Partnering without an exit clause. A partner relationship without a clear "we run this internally by month 24" plan becomes a permanent dependency.
Related frameworks