/ THE SHORT ANSWER
Choose buy when the workflow is standard and the product meets requirements without strategic customization. Configure when a platform covers the core job but needs workflows, integrations, and governance. Build when the process is differentiating and control, integration, or user experience justifies permanent engineering ownership. Partner when discovery or delivery skills are missing but the business can own the outcome. Score all four routes on 12 factors, validate the top route with a bounded proof, and preserve an exit path.
- 01Treat buy, configure, build, and partner as four distinct routes with different owner and vendor responsibilities.
- 02Score the business workflow before comparing vendors; a high-feature product cannot repair an undefined process.
- 03Use 12 evidence-backed factors and record confidence, non-negotiable gates, and missing information separately from the total score.
- 04Whole-life cost includes integration, evaluation, security, change, support, monitoring, internal time, and exit—not only license or model fees.
- 05Validate the leading route with representative data, acceptance tests, ownership artifacts, and a reversible commercial commitment.
/ dotSuper point of view
Build versus buy is a false binary. The defensible decision compares four delivery routes against the same business problem, evidence, risks, and whole-life responsibilities. The winning route is the least complex option that meets the workflow's differentiating, data, integration, evaluation, governance, reliability, adoption, ownership, time, and economic requirements.
There are four practical routes—not two
A build-versus-buy discussion often mixes three decisions: whether the business needs a standard application or a differentiated system, whether internal people or an external partner will deliver it, and who will operate it after launch. Separate those decisions. A packaged application can still require a consulting partner; a custom system can still rely on managed model APIs; a low-code platform can be configured internally or by an agency.
UK government AI procurement guidance recommends starting with the challenge, assessing data and risk early, keeping requirements open to alternative solutions, using multidisciplinary evaluation, considering whole-life support, and addressing black-box behavior and vendor lock-in. Those principles apply beyond public procurement because they prevent the route or vendor from being selected before the problem is understood. [Evidence: UK Guidelines for AI Procurement, accessed 2026-08-30.]
| Route | Best starting condition | Buyer owns | Main risk |
|---|---|---|---|
| Buy | Standard workflow with a mature product fit | Configuration, adoption, vendor management, and business outcome | Process compromise, data constraints, or lock-in hidden by fast deployment |
| Configure | Platform covers core capabilities but the workflow needs integration and control | Workflow design, platform governance, testing, and ongoing configuration | Low-code complexity becomes an unowned production system |
| Build | Workflow is differentiating or requirements cannot be met proportionately by products | Product, code, data, evaluation, operations, security, and roadmap | Permanent engineering and support burden exceeds strategic value |
| Partner | Internal discovery or delivery capability is missing or constrained | Business decision, accountable owner, acceptance, and eventual operating model | Dependency persists because transfer and exit were never designed |
Freeze the decision context before scoring
The scorecard is only useful if every route is evaluated against the same problem. Write a one-page decision context: named users, current workflow, baseline, desired outcome, data classes, systems touched, consequence of error, volume, latency, service window, legal or policy constraints, internal skills, budget range, and decision deadline. State what is explicitly out of scope.
Microsoft's AI Readiness Assessment covers business strategy, governance and security, data foundations, AI strategy and experience, organization and culture, infrastructure, and model management. The scorecard on this page is narrower—it chooses a delivery route for one defined workflow—but those readiness dimensions reveal dependencies that a project-level comparison can otherwise miss. [Evidence: Microsoft AI Readiness Assessment, accessed 2026-08-30.]
- Decision owner and affected users
- Current baseline and desired measurable change
- Information, systems, and integrations in scope
- Error consequence, human authority, and fallback
- Non-negotiable security, privacy, legal, and operational requirements
- Time, budget, internal capacity, and expected useful life
The 12-factor scorecard
Score each route from one to five for every factor, where five means the route is strongly suited to the requirement. Add a confidence grade—high, medium, or low—and cite the evidence. Do not confuse a precise number with certainty. Unknown integration behavior, unpublished retention terms, or an untested workflow should lower confidence even when the initial score appears attractive.
NIST's AI Risk Management Framework organizes risk work around govern, map, measure, and manage. At project level, that means understanding context, business value, actors, requirements, risk tolerance, measurement, and lifecycle management. Use the scorecard as a decision record inside that larger process, not as a replacement for risk assessment. [Evidence: NIST AI RMF and AIRC Core, accessed 2026-08-30.]
| Factor | Key question | What strong evidence looks like |
|---|---|---|
| 1. Strategic differentiation | Is this workflow a source of advantage or mainly standard work? | Customer, margin, speed, quality, or IP rationale tied to strategy |
| 2. Functional fit | How much of the real workflow is met without harmful compromise? | Scenario test across normal work and exceptions |
| 3. Data fit | Can the route use the required data lawfully, accurately, and with correct permissions? | Data map, provenance, quality sample, access and retention terms |
| 4. Integration fit | Can it work with systems, identities, and events already in use? | Documented interfaces, sandbox proof, latency and failure behavior |
| 5. Evaluation and control | Can behavior be tested, explained enough for the use, reviewed, and corrected? | Representative evaluation set, thresholds, logs, approval and rollback |
| 6. Security and privacy | Does the route meet the actual risk and compliance boundary? | Architecture, subprocessors, isolation, encryption, access, incidents and deletion evidence |
| 7. Reliability and operations | Can the business meet uptime, recovery, monitoring, and support needs? | Service levels, observability, runbook, recovery test and accountable operator |
| 8. User adoption | Will the route fit the work and can users verify or recover? | User research, workflow prototype, training plan and adoption owner |
| 9. Internal capability | Can the organization deliver and operate its side of the route? | Named roles, available capacity, skills, budget and escalation path |
| 10. Time to useful outcome | How quickly can representative value be tested, not merely demonstrated? | Credible plan with dependencies, gates, and acceptance dates |
| 11. Whole-life economics | What will discovery, delivery, use, change, support, risk, and exit cost? | Three-year scenario with internal time and sensitivity ranges |
| 12. Ownership and reversibility | Can the business continue, switch, or stop without losing critical assets? | IP terms, exports, open interfaces, documentation, handover and tested exit |
How the routes tend to score
Buying tends to score well on speed, known support, and standard-process fit when a mature product matches the requirement. It can score poorly on differentiation, deep integration, workflow control, data terms, or reversibility. The buyer should not assume that enterprise branding resolves those issues; test the exact plan, feature, geography, and contract.
Configuration can fit tailored workflows inside a platform; build can fit differentiating work backed by durable engineering capacity; partnering can add discovery and delivery skills. None removes the buyer's responsibility for workflow ownership, testing, operations, and risk.
Three hypothetical scenarios
For predictive maintenance on safety-relevant equipment, none of the routes should be selected from a generic score alone. Data adequacy, asset physics, failure consequences, OT cybersecurity, validation, and operational standards become gates. A specialized industrial platform and systems-integration partner may be necessary; a general AI boutique would be an inappropriate prime contractor unless it can evidence the required competence and works inside the correct assurance structure.
| Scenario | Likely route to test first | Why | Critical diligence |
|---|---|---|---|
| Standard meeting assistance | Buy | Common workflow and low strategic differentiation | Exact privacy, retention, language, identity, and human-use terms |
| Proprietary industrial quote support | Configure or partner-assisted build | Differentiating rules and integrations may exceed packaged fit | Source traceability, ERP integration, approvals, commercial error, and handover |
| Safety-relevant predictive maintenance | Specialist platform plus industrial integration partner | High consequence and domain-specific data, engineering, and assurance | Fitness for purpose, OT security, validation, standards, fallback, and accountable authority |
Validate the leading route before committing
The top score identifies what to test, not what to purchase. Run a bounded proof using representative inputs, users, systems, and failure cases. For packaged software, test configuration limits, data exports, integration behavior, support, and real user fit. For a platform, build the riskiest integration and control path. For a custom route, test the uncertain technical and workflow assumption before funding full delivery. For a partner, evaluate both the system and the team's method, documentation, communication, and transfer behavior.
Commercial terms should preserve reversibility. Define ownership and licenses for code, workflows, prompts, approved knowledge, schemas, evaluation sets, logs, analytics, documentation, and accounts. Specify exports, deletion, support, service levels, change control, model or subprocessor changes, security incidents, termination assistance, and continued operation. The UK guidance explicitly recommends whole-life thinking and lock-in mitigation; those requirements belong in the agreement, not only in a slide deck.
Where dotSuper fits in the decision
Inference: dotSuper may fit a bounded partner-assisted workflow when the error boundary is manageable, integrations are proportionate, and the client wants documentation and ownership. This follows from dotSuper's public workflow-first positioning; it is not evidence of competence in every architecture or risk class. The scorecard should route buyers elsewhere for mature SaaS needs, safety-critical control, complex robotics, plant-wide OT integration, or high-scale enterprise platforms.
What this page cannot conclude
- 01The 12-factor scorecard and any suggested weighting approach are planning tools created for this article, not an official NIST, Microsoft, or government standard.
- 02Vendor products, hosting, data terms, prices, integrations, and licenses change; verify the exact plan and contract at the time of purchase.
- 03A numerical score cannot override legal, safety, privacy, cybersecurity, or operational gates.
- 04Specialist legal, security, safety, financial, and industry assurance may be required before procurement or deployment.
Sources
- 01Guidelines for AI ProcurementUK Government · accessed Aug 30, 2026
- 02AI Readiness AssessmentMicrosoft Learn · accessed Aug 30, 2026
- 03AI Risk Management FrameworkNational Institute of Standards and Technology · accessed Aug 30, 2026
- 04AI RMF CoreNIST AI Resource Center · accessed Aug 30, 2026
- 05AI Readiness SprintdotSuper · accessed Aug 30, 2026
Turn an AI idea into an evidence-backed route decision.
The AI Readiness Sprint maps one workflow, its baseline, data, users, risks, integration boundary, and ownership so you can decide whether to buy, configure, build, partner, or stop—before a platform choice makes the decision for you.
Run the scorecard with dotSuper