A Digital Consulting Plus methodology
English
← Full mapCurated public summary
Index
Handbook
01DCP Flow: what it is and why it exists02How DCP Flow works03How to start a project04Kai and working with AI agents04AKai operational capabilities05Institutional Prompt Cookbook06Solution Discovery explained for humans07Architecture, stack, and technology ecosystem07ATool & MCP Registry07BHostinger MCP for DCP websites and hosting08Quality Gates, QA, security, and evidence08AQuality profiles and testing strategy09Git, branches, PRs, and multi-agent work10Deploy, release, support, and operational evolution10AContainer First and standardized host operations10BPractical Container First demo11How DCP Flow evolves12Real cases and lessons learned13How to teach DCP Flow14Practical DCP Flow use cases15End-to-end playbooks: Web and Laravel
Entry 0633%
33%7 / 21
Entry 06PUBLIC HANDBOOK

Solution Discovery explained for humans

Problem, Capability Matrix, SaaS, OSS, components, licensing, security, reproducible shortlist, Golden Flows, GAP/TCO/risk, ADR, and ADOPT/CONFIGURE/INTEGRATE/EXTEND/BUILD.

Source & authority

Public explanation

PUBLIC HANDBOOK
Based on
Human Handbook 06 — Solution Discovery explained for humans
Related normative sources
  • NORMATIVE SOURCEStandard · Development Methodology
  • NORMATIVE SOURCEStandard · Solution Discovery Gate
  • NORMATIVE SOURCEStandard · Existing Solution Assessment
Authority
Public explanation — NON-NORMATIVE
Summary

Problem, Capability Matrix, SaaS, OSS, components, licensing, security, reproducible shortlist, Golden Flows, GAP/TCO/risk, ADR, and ADOPT/CONFIGURE/INTEGRATE/EXTEND/BUILD.

Solution Discovery prevents reflexive building. Before custom development, DCP Flow requires investigating what exists, testing material candidates, and measuring GAP across functional and technical criteria.

The discovery journey

Start with the problem and a Capability Matrix, review SaaS as benchmark, full OSS products and components, then validate licensing, security, compliance, maintainability, and dependency risk. Test the shortlist through reproducible Golden Flows.

Key points
  • SaaS benchmark.
  • Full OSS Product Discovery.
  • Engines and components.
  • Reproducible shortlist and Golden Flows.

ADOPT, CONFIGURE, INTEGRATE, EXTEND, or BUILD

Record the final decision in an ADR. ADOPT uses an existing solution with minimal changes; CONFIGURE uses supported configuration; INTEGRATE connects existing capabilities; EXTEND adds capabilities through supported extension mechanisms; BUILD creates custom implementation when the previous alternatives do not reasonably satisfy the outcome or there is explicit material justification.

Key points
  • Functional and technical GAP.
  • TCO and complexity.
  • Security, compliance, and lock-in.
  • Maintainability and dependency risk.

Discovery is an evidence path, not a list of links

The Gate starts with Problem Definition and a Capability Matrix, uses SaaS as a benchmark, searches for complete OSS products, and then evaluates engines or components. Licensing, security, and compliance filter material candidates. When behavior matters, the shortlist is deployed reproducibly and Golden Flows are executed before GAP, TCO, and risk are assessed.

Key points
  • 1 Problem → 2 Capabilities.
  • 3 SaaS → 4 Full OSS → 5 Components.
  • 6 License/Security → 7 Reproducible shortlist.
  • 8 Golden Flows → 9 GAP/TCO/Risk → 10 ADR.

Five current decisions, evaluated proportionally

DCP Flow evaluates ADOPT → CONFIGURE → INTEGRATE → EXTEND → BUILD as a preference, not a mechanical ladder. ADOPT uses an existing solution with minimal changes; CONFIGURE uses supported configuration; INTEGRATE connects existing capabilities; EXTEND covers gaps through supported mechanisms; BUILD creates a custom implementation only when earlier alternatives do not reasonably solve the outcome or an explicit material justification exists.

Key points
  • ADOPT: minimal changes.
  • CONFIGURE: supported configuration.
  • INTEGRATE: connect existing capabilities.
  • Prefer EXTEND before BUILD when fit, risk, TCO, upgrades, lock-in, architecture, and operating capacity justify it.

Executing candidates and documenting the decision prevents decorative discovery

Finding a repository or reading a README does not validate a solution. A POC records version, runtime, installation, non-sensitive configuration, errors, and limits; Golden Flows may be PASS, PARTIAL, FAIL, BLOCKED, or NOT RUN. The ADR preserves candidates, evidence, trade-offs, and consequences so the decision survives the conversation that created it.

Key points
  • Repository found ≠ candidate validated.
  • Use a reproducible shortlist when runtime behavior matters.
  • NOT RUN is never PASS.
  • ADR turns research into decision memory.
Contextual glossary＋
Solution Discovery

Process of investigating real alternatives and proportionally evaluating ADOPT → CONFIGURE → INTEGRATE → EXTEND → BUILD before a material decision.

ADOPT

Use an existing solution with minimal changes when it reasonably covers the outcome.

CONFIGURE

Solve the outcome through supported configuration of an existing solution.

INTEGRATE

Connect existing capabilities or systems when the governed combination solves the outcome.

EXTEND

Expand a platform through supported extension mechanisms to cover real gaps.

BUILD

Create a custom implementation when ADOPT, CONFIGURE, INTEGRATE, and EXTEND do not reasonably solve the outcome or an explicit material justification exists.

IMPLEMENT

Historical terminology: former umbrella term for implementing an existing solution; superseded by ADOPT / CONFIGURE / INTEGRATE / EXTEND / BUILD.

GAP

Difference between required capabilities and those available in an evaluated alternative.

TCO

Total cost of ownership including operation, maintenance, dependency, and evolution.