Choose What to Build, Buy or Integrate

The method, in brief

Which sourcing commitment can the business sustain and exit?

Break the workflow into components, compare feasible build, buy and integration options on the same scope and horizon, and include internal labour, maintenance, failure recovery and exit. Price alone does not determine the best operating commitment.

Why this framework matters

Sourcing is a choice about ongoing responsibility as much as initial implementation.

Break the workflow into components, compare feasible build, buy and integration options on the same scope and horizon, and include internal labour, maintenance, failure recovery and exit. Price alone does not determine the best operating commitment.

Audience and decision

For a business owner, technology lead, procurement lead and future system operator selecting how to deliver a defined workflow improvement. Decide which components to buy, configure, integrate or build, and which responsibilities the business is willing to retain. Use this after the problem is understood and before a supplier proposal makes the architecture feel inevitable.

The decision is usually component-specific. A business might buy document capture, build a small approval interface and integrate both with an existing ERP. Treating the whole system as a binary build-or-buy choice can hide the actual operating burden. Allow two hours for appraisal, then run targeted supplier or technical tests before committing.

Research and source ledger

Sources accessed 16 September 2026.

Lineage: Build/buy appraisal and whole-life cost are established practices. The component obligations table, substitution rehearsal and decision expiry rule are dotSuper synthesis. The worksheet does not adapt a proprietary sourcing matrix or claim a universally optimal make/buy formula.

Existing approaches and limitations

Feature comparisons can reward breadth while ignoring the few requirements that determine viability. A cheap licence can conceal implementation, review, integration and exit costs. A bespoke build can offer control while creating dependence on one developer. An open-source licence can permit use without providing maintenance or guaranteeing security. A vendor's regional data centre may address one requirement while leaving support access, subprocessors or contractual terms unresolved.

The proposed method starts with a real workflow and tests obligations through its lifecycle. It asks what the organisation must do when the system changes, fails or is replaced. The ability to export data is useful, but an untested export file is not yet a workable exit plan.

Structure and rationale

Prepare a component map, an option obligations table, a whole-life cost range and an exit rehearsal plan. The component map separates input capture, business logic, model or rules, review interface, integration, records, monitoring and support. Not every workflow needs every component.

For each option, examine must-have outcomes, data and security conditions, interoperability, ownership and rights, operating capability and replacement burden. Apply must-have conditions before comparing cost. A low-priced option that cannot meet a necessary permission requirement is not rescued by strengths elsewhere.

Inputs and preparation

Bring a bounded workflow specification, expected normal and peak usage, representative permitted test cases, existing systems and actual team capacity. Collect vendor terms and dated quotations when available. Where terms or prices are unknown, use a visibly marked assumption and a follow-up question.

Define the evaluation horizon, such as 24 months, and state that it is a planning choice. Include initial work, recurring charges, human review, administration, support, change and exit. Separate cash expenditure from internal staff time. Identify costs that scale with volume and those that occur regardless of adoption.

Facilitation and use

1. Specify the outcome and hard conditions, 15 minutes. List a short set of observable requirements. Avoid describing a preferred vendor's features as the need. Record which conditions come from the customer, law, internal policy or engineering constraints. 2. Decompose the workflow, 15 minutes. Identify commodity components and those that express distinctive business rules. Ask whether the apparent uniqueness is essential or simply an inherited workaround. 3. Develop credible options, 20 minutes. Compare an existing-system configuration, an available product, an integration approach and a targeted custom build where appropriate. Include a process-only alternative if it could meet the outcome. 4. Apply feasibility gates, 20 minutes. Check rights, access, supported interfaces, acceptable deployment and available operators. Mark missing evidence rather than assuming a sales statement answers every condition. An unsupported API dependency should be visible. 5. Build cost scenarios, 20 minutes. Use low, expected and high usage assumptions only when the underlying quantities can be described. Include failure recovery, review and supplier-change effort. Do not use a precise discounted valuation when basic cost inputs remain unknown. 6. Test the hardest uncertainty, 15 minutes. Give each viable option a representative difficult case. Test access controls, integration behaviour, exports and user review, not just a polished demonstration. Record what the test did not cover. 7. Assign lifecycle ownership, 10 minutes. Name who handles changes, bills, permissions, incidents, quality drift and renewal. Confirm that the person has capacity. A supplier can perform tasks while a client remains accountable for the operational decision. 8. Record the decision and expiry, 5 minutes. Select a conditional option, unresolved questions and a reconsideration trigger such as a price change, unsupported integration or material increase in usage.

Decision definitions and assumptions

Build means developing a component whose maintenance the organisation must arrange. Buy means using an existing product within supported capabilities. Integrate means connecting components and owning the behaviour between them, even when neither component is custom. Configuration can be cheaper than modification but still requires testing and support.

Classify requirements as essential, useful or optional with a reason. A failed essential requirement excludes the current option unless the requirement itself is legitimately revised. Among feasible options, compare costs, control and maintenance burden explicitly. No universal weighting or “ownership percentage” is proposed. Intellectual-property ownership, operational access and practical ability to maintain are separate facts.

Worked example: illustrative, not supplier quotations

A hypothetical distributor needs a quotation-review workspace connected to its ERP. Over a chosen 24-month horizon, Option A is an existing product with AED 12,000 setup, AED 2,000 monthly service fees and AED 1,000 monthly internal administration. Its visible total is AED 84,000 before exit work and exceptional usage.

Option B is a targeted build with AED 55,000 initial development, AED 1,200 monthly infrastructure and AED 1,500 monthly maintenance. Its visible total is AED 119,800 before staff review and exit. Both calculations are illustrative and omit costs that must be added before a real decision. Neither is a forecast of dotSuper pricing.

Option A initially looks preferable. A difficult-case test reveals that it cannot export the source-document links required for audit and replacement. The supplier proposes a supported enhancement, but timing is unconfirmed. Option B can meet the requirement, yet the buyer has no maintenance owner. Both options therefore have unresolved conditions. Price alone cannot determine the choice.

A third option configures the existing ERP intake process and uses a small extraction service with a customer-owned evidence store. It still requires a tested interface, permissions and maintenance estimate. The next decision is a limited integration assessment, not immediate purchase. The team could ultimately choose A if the export condition is met, or stop if the improvement cannot justify full operating cost.

Outputs, failure modes and validation limits

Deliver a component-level decision record, requirement evidence, cost assumptions, responsibility table and exit test. The recommendation should state what the client receives, what remains licensed and what it can operate independently. “Your team owns it” needs this practical explanation.

Failures include comparing only first-year fees, assuming custom code eliminates dependency, ignoring access revocation, treating a backup as a tested recovery procedure and accepting terms that conflict with the intended data use. Another error is demanding custom ownership where a supported commodity product would serve the business well.

A counterexample is a regulated workflow with stringent assurance requirements. A small custom build may appear flexible but demand a validation burden beyond the team's capacity. Conversely, a product that covers most features may still be unsuitable if its one missing capability is essential to the workflow.

This protocol does not replace technical, security, procurement or legal review. Validate the decision with representative trials and a handover rehearsal. Track actual operating costs against assumptions after deployment. The proposed combined worksheet has not been shown empirically to reduce total cost or supplier risk.

Working files and reuse

The five-page PDF includes a visual reference, two fillable worksheet pages, an illustrative worked example and a facilitator/source guide. An expandable CSV working log is also available.

All examples are illustrative, not measured client results. Original component appraisal. Not a universally optimal formula, supplier recommendation or legal review. Costs are illustrative and incomplete. UK public-sector obligations are not imported into Gulf private businesses. No third-party canvas is reproduced.

Original dotSuper material prepared for review. No public reuse licence has been assigned. Third-party source material retains its own terms.

The PDF is not represented as a tagged PDF/UA document. The text on this page provides a readable alternative to the diagram and method.

Sources, context and limits

Keep the evidence beside the method.

• Original component appraisal. Not a universally optimal formula, supplier recommendation or legal review. Costs are illustrative and incomplete. UK public-sector obligations are not imported into Gulf private businesses. No third-party canvas is reproduced.
• This combined dotSuper method is research-informed and has not been field validated. Workshop agreement and a completed template are not proof of effectiveness.
• Worked examples are hypothetical. Country examples and intended regional audience do not establish country-wide or region-wide effectiveness.
• Source access and adaptation limits are recorded in the source ledger. Attribution does not imply endorsement or a licence to reproduce third-party artwork.

1. Define your purchasing strategy

   UK Government · accessed Sep 16, 2026

2. Technology Code of Practice

   UK Government · accessed Sep 16, 2026

3. Guidelines for AI procurement

   UK Government · accessed Sep 16, 2026

4. AI RMF Playbook

   NIST · accessed Sep 16, 2026

5. Business Model Canvas

   Strategyzer · accessed Sep 16, 2026

Bring it into the work

Start with one real decision

Bring one sourcing decision and compare the costs, responsibilities and exit conditions.