Self-Build vs Platform: Three-Year Build-vs-Buy TCO

A self-built RAG prototype can run quickly: install a vector database, chunk documents, connect a model, and show a demo within days. In production, the work concentrates around the main chain:

• A document changes layout, parsing fails, and nobody can tell which step broke.
• The same document cannot be retrieved with a different phrasing because one body has only one index.
• Dozens of documents fail in the training queue, and the only available fix is rerunning the whole knowledge base.
• A workflow fails at step five, requiring breakpoint recovery and idempotent retry.
• Someone asks where last month's calls spent money, and cost needs to be split by parsing, vectorization, retrieval, and generation.
• The business team asks for Feishu and WeCom, and the channel adapter needs to be written from scratch.
• Security review arrives and asks whether code execution nodes have a sandbox, external tools have SSRF protection, secrets are managed safely, and audit logs are retained long enough.

Production quality depends on document quality, chunking method, update frequency, permission boundaries, retrieval configuration, and model capability. Each item needs a clear owner, regression set, and operations budget.

Long-term work for self-building or running open source directly falls into four groups. Platform procurement also requires a separate review of vendor support responsibility. List person-days and service scope by group so the three-year TCO is comparable.

2.1 Group One: Parsing, Retrieval, and Knowledge Maintenance

Document parsing, chunking, indexing, retrieval, ReRank, citation tracing, and retraining queues.

Production needs fallback parsing for multiple layouts, adjustable chunking, multiple indexes for one body, independent index editing, single-item training queue repair, retrieval history review, and citation location.

2.2 Group Two: Agent and Workflow Runtime

Agent / workflow runtime, failure recovery, human interaction, debugging, logs, and evaluation.

The three key items are failure recovery (node retry idempotency and queue backlog), human interaction (pause, form confirmation, and in-place recovery), and evaluation (fixed question-set regression).

2.3 Group Three: Security and Governance

Model adaptation, tool security, secrets, SSRF, code sandboxing, authentication, RBAC, SSO, audit, and multi-tenancy.

Security review and customer compliance will ask for model adaptation, tool security, secrets, SSRF, code sandboxing, authentication, RBAC, SSO, audit, and multi-tenancy. Code sandboxing and tenant isolation belong to runtime architecture and should be checked early in solution design.

2.4 Group Four: Publishing, Operations, and Support

Publishing channels, API compatibility, upgrade rollback, backup recovery, monitoring and alerts, on-call, and user support.

An all-hands knowledge base needs on-call, alerts, backup recovery, and user support. Wrong answers, slow answers, and outages all need clear handlers and person-day budgets.

Vendor support is the fifth cost variable. The self-build side carries it through team on-call, while the platform side defines it through support tiers and service checklists:

Convert self-build on-call into person-days and put it into three-year TCO. On the platform side, write coverage hours, first-response targets, repair responsibility, and upgrade rollback into the service checklist. Record first-response targets separately from repair time limits. Final commitments should be based on the contract.

2.5 Use Requirement Priority to Decide the Self-Build Boundary

Mark each item as "required / optional / future": required items cover parsing, retrieval, basic permissions, and publishing channels; optional items include evaluation systems, cost split, and session labeling; future items include multi-tenancy, clustering, and cross-region disaster recovery.

Internal knowledge bases with few required items, deferrable optional items, and clear future items are good candidates for self-build. When SSO, audit, multi-tenancy, and code sandboxing enter the required list together, the self-build scope expands into platform engineering. The requirement-priority table should become the direct input for the POC and both quotes.

Orchestration, RAG, ReRank, external tools, and observability add length to the call chain. Platform options need latency, token, parsing, and storage costs included in acceptance.

Choose one real business chain and compare direct model calls, self-built orchestration, and the platform option. Record end-to-end P95 / P99 latency, tokens, parsing and storage cost, failure rate, development person-days, and operations person-days.

Platform options can choose models, storage, vector backends, APIs, and deployment methods according to enterprise requirements. Workflow configuration and commercial features create migration cost. The POC should record application and data export, model switching, vector-backend switching, backup recovery, and API compatibility results, then write the exit path into the procurement checklist.

4.1 Three-Year TCO Calculation Table

The final output is three tables: three-year cash flow, person-days, and risk reserve, plus sensitivity analysis for member count, document volume, and request volume.

4.2 Six Required Test Categories

Version stability, upgrade rollback, data recovery, concurrency, security, and support response should enter the production acceptance checklist, with upgrade rehearsals, backup recovery, long-running load tests, security cases, and fault injection scheduled separately.

The self-build versus platform conclusion should be based on cost, person-days, delivery time, and risk reserve under the same three-year requirements checklist.