Start with the requirement that matters
A vendor demo may answer a clean question from a prepared document. A custom system may connect every source and still fail to explain who owns the answer. Compare the operating result, not the demo surface.
Use four options, not two
The real choice is often configure, integrate, buy a managed product, or build a custom context and action layer. Configuration is sensible when the product's source, permission, and lifecycle model fits. Integration is useful when the missing value sits between existing systems.
Custom development becomes more reasonable when the workflow creates strategic value, recurs at meaningful volume, or needs controls the product cannot expose. It also creates a long-term support obligation.
Compare control and migration
Ask who owns the source mapping, identities, permissions, derived records, evaluation set, logs, and feedback. Ask how you export the knowledge structure and how a future model or vendor change would work. Microsoft Graph's connector model shows why ingestion, identity, and access are separate implementation concerns.
Price the operating system
Include integration maintenance, source changes, support, evaluation, admin time, model usage, incident response, training, and eventual migration. A low subscription can still be expensive if every exception becomes manual work. A custom build can be wasteful if the problem is ordinary document search.
Run a bounded proof
Choose one workflow and use the same acceptance set against each option. Include missing evidence, conflicting sources, revoked access, update and deletion, a real owner handoff, and an action that requires approval. Keep the loser in the record. The point is to make the decision explainable, not to force a build.
Score the same requirements for every option
Create a matrix covering source coverage, identity, permissions, freshness, evaluation, tool boundaries, migration, support, and total operating cost. Test each option with the same real questions and the same failure cases. A feature list misses the cost of maintaining connectors and repairing stale answers.
Configuration is often enough when the workflow is ordinary and the product exposes the required controls. Integration is useful when the value sits between systems. Custom work is justified only when the workflow or control model is strategic and measurable.
Run a bounded proof with an exit rule
Choose one workflow, one owner, one acceptance set, and one time-boxed proof. Include missing evidence, conflicting sources, revoked access, updates and deletions, a human approval, and a real handoff. Define what would make you stop, buy, change scope, or continue.
Keep the decision record, including why the losing options failed. That record prevents the team from reopening the same debate when a vendor changes a feature or a new model appears.
The LeanOrchestr Business Brain connects approved company sources, preserves access boundaries, and turns useful context into a maintained operating layer. Start with one question, one accountable owner, and an evaluation set you can rerun.
Sources and verification
Primary product, architecture, risk, and security sources checked on 10 September 2026. Product behavior can change, so verify current plan and admin documentation before implementation.