When this framework fits
Use it when
- The workflow and required capability are defined well enough to compare implementation paths.
- A purchased product, custom system, or integrated combination could plausibly meet the need.
- The choice affects cost, control, delivery time, data, or the organization's ability to change later.
Do not use it alone when
- The team has not yet established whether the work should be automated or redesigned.
- Security, privacy, legal, procurement, or regulatory approval requires specialist assessment.
- The choice is being made without a process owner or a team able to operate the result.
The five-step build, buy, or integrate method
1. Define the capability and strategic boundary
Describe the job in operational terms: users, inputs, decisions, outputs, volume, exceptions, permissions, service level, and the consequence of failure. Separate the required outcome from the current workflow. Reproducing every historical step can preserve complexity that the new system should remove.
Then decide what must remain distinctive. Logic that encodes a genuine operating advantage, proprietary model, or critical customer experience may justify more control. Commodity functions such as authentication, notifications, document storage, or standard approvals often do not. Use automation selection before this framework if the capability itself is still in doubt.
2. Make the viable options comparable
Define a small set of real options against the same scope. "Buy" may mean configure a product and accept its process. "Integrate" may mean keep a commercial system of record while adding a narrow workflow, data, or interface layer. "Build" may range from a focused internal tool to a maintained application. Include defer or retain the current process when it remains viable.
For each option, show what is included, what remains manual, which system owns each record, and where exceptions go. Compare the same service level and adoption outcome. A product demonstration with sample data is not equivalent to an operated workflow with migration, permissions, support, and month-end reconciliation.
3. Model lifecycle cost and change load
Use a common time horizon and include implementation, configuration, licenses, usage, integration, migration, testing, training, support, monitoring, vendor management, upgrades, and eventual replacement. Add internal time explicitly. A lower invoice can still require substantial operational ownership, while a larger initial build can create a continuing maintenance obligation.
Model ranges rather than a single total. Volume, customization, vendor pricing, change frequency, and exception rates can move the answer. Show who absorbs each change. A purchased platform may push work into process adaptation; a custom system may push it into engineering; an integration-heavy path may create reconciliation and incident work across organizational boundaries.
4. Assess control, failure, data, and exit
Map decision rights over roadmap, access, permissions, audit history, data model, release timing, and service recovery. Identify failure modes across the full system, including vendors and interfaces. State what happens when an API changes, a sync partially fails, a user loses access, a record conflicts, or the provider becomes unavailable.
Test reversibility before commitment. Confirm data export, schema clarity, identity ownership, contractual exit, transition support, and the effort required to move. Control has value only when the organization can exercise it. Owning source code without documentation, tests, operators, or deployment access may provide less practical control than a well-governed external service.
5. Run the smallest decisive test and record the choice
Test the uncertainty most likely to reverse the ranking. That might be an API's real behavior, migration quality, permission depth, user adoption, exception handling, performance under representative volume, or the effort to change one critical rule. Use representative work and include a failure case. A polished happy path does not retire operating risk.
Write an architecture decision record with the chosen boundary, alternatives, evidence, assumptions, trade-offs, owner, and review date. Add triggers such as price changes, volume, repeated exceptions, roadmap divergence, control failures, or mounting maintenance effort. The decision should remain stable while its assumptions hold and become reviewable when they do not.
Evidence requirements
| Evidence | Decision it supports | Minimum discipline |
|---|---|---|
| Capability definition | What the system must enable | Users, volumes, decisions, outputs, exceptions, permissions, and failure consequences |
| Current workflow evidence | Which work and cost may actually change | Observed steps, variants, handoffs, rework, and ownership |
| Option boundary | Whether alternatives are being compared fairly | Included scope, manual residue, systems of record, and service level |
| Lifecycle cost model | Which path is economically supportable | Internal and external cost ranges over a common horizon |
| Control and exit review | Whether dependency and reversibility are acceptable | Data, access, contract, portability, recovery, and transition conditions |
| Representative test | Whether the load-bearing uncertainty is retired | Realistic data, exceptions, success criteria, owner, and documented result |
Hypothetical Example
An evidence-review workflow needs one source of truth
A hypothetical research team manages intake, source collection, review, approval, and final handover across spreadsheets, email, and shared folders. The capability need is already established: every assignment requires consistent status, permissions, evidence links, and an auditable approval trail.
A custom application offers exact workflow control but would require the team to own identity, document handling, notifications, reporting, and ongoing changes. A commercial work-management product handles permissions and task state quickly, yet its evidence structure and final export are weak. A third option keeps the commercial product as the workflow system and adds a narrow integration that validates evidence records and produces the handover package.
The team tests the integration path using representative assignments, permission changes, rejected evidence, duplicate records, and an API interruption. It chooses that path only after the test proves recoverable synchronization and usable exports. The architecture record sets review triggers for vendor pricing, API limits, exception volume, and maintenance effort. This is an invented example, not a claim about an engagement or outcome.
Failure modes
Feature-checklist selection: option count replaces workflow fit. Free-software fantasy: internal time, support, and change are excluded from custom cost. License-only comparison: migration, configuration, integration, and adoption disappear from purchased cost. Strategic-everything: ordinary requirements are treated as unique to justify a build. Integration handwave: interfaces are assumed to be reliable without ownership or reconciliation. Lock-in indifference: exit is considered only after data and process depend on the vendor. Proof-of-concept theater: the test avoids exceptions and operational volume. Sunk-cost permanence: the original choice is defended after its assumptions fail.
Build, buy, or integrate checklist
- The capability and process owner are named before technology options are ranked.
- Users, decisions, outputs, volumes, exceptions, permissions, and failure consequences are explicit.
- Differentiating logic is separated from commodity functionality.
- Build, buy, integrate, defer, and the current process use a comparable boundary.
- Manual residue and system-of-record ownership are visible for every option.
- Lifecycle cost includes internal time, change, operation, support, and exit.
- Security, privacy, legal, procurement, and regulatory needs have appropriate owners.
- Data portability, recovery, and transition conditions are tested before commitment.
- The decisive test includes representative data and at least one failure case.
- The decision record contains assumptions, trade-offs, owners, and review triggers.
Limitations
Costs and capabilities can change after a decision, and pilots rarely reveal every operational condition. Vendor roadmaps, contract terms, security posture, integration behavior, and team capacity require current evidence and sometimes specialist review. Custom software can create strategic control or an avoidable maintenance burden depending on the boundary and operating model. A framework cannot remove judgment. It can make the trade-offs, unknowns, and revisit rules explicit.
Related Services
Related Insights
Choose the boundary before choosing the tool
A defensible software decision compares capability, cost, control, failure, and exit on one operating model.