Quick answer
Buy when an existing product can complete your workflow within your access, review, and operating requirements. Configure and integrate when the product fits but needs connections or business rules. Build a custom workflow when a necessary capability remains unsupported and its value justifies owning the implementation. Test those boundaries on representative cases before committing. Building does not necessarily mean training your own model.
Separate the software choice from the delivery work
Microsoft’s AI strategy guidance distinguishes ready-made software, low-code tools, managed platforms, and infrastructure services, and starts with the business problem. The practical buying question is which responsibilities your team needs to take on. Buying a subscription may still leave integration, acceptance testing, and operator training to you.
For this decision, compare three delivery options: use an existing application; configure that application and connect it to your systems; or build a custom workflow around available components. A custom workflow can use a commercially supplied model. The owned work may be the process logic, review interface, integration, and recovery behavior rather than the model itself.
Compare fit before comparing feature lists
Write down what starts a case, what completes it, and the conditions that must stop it. Give each option the same examples and mandatory requirements. The matrix below is a proposed decision method, not an industry scoring standard. A failed access or approval requirement should remain visible even if the option scores well elsewhere.
| Option | A reason to choose it | Evidence before committing |
|---|---|---|
| Use existing software | Its supported process covers the required work | Your normal cases and exceptions finish with acceptable review effort |
| Configure and integrate | The core process fits; the remaining gaps have supported extension points | Required reads, writes, approvals, and recovery work through those interfaces |
| Build a custom workflow | A necessary behavior is missing and adapting the business process is unacceptable | A bounded feasibility test proves the difficult behavior; an owner accepts ongoing maintenance |
Worked example: a support reply with a refund request
Consider a hypothetical support team whose current help desk offers AI reply drafts. The team wants drafts grounded in approved policies, with an employee reviewing each message. If the existing feature respects case access and handles the team’s examples well, buying that capability could satisfy the requirement. This is an illustrative decision, not a PlatformBridge customer result.
Now add a requirement to check an order’s delivery status before drafting. If the help desk provides a supported connector or extension, configuration and integration may close the gap. Test an unavailable order system and an ambiguous order match as well as a successful lookup.
Finally, suppose a refund recommendation needs evidence from several systems and a separate approval record. First check whether supported extensions can enforce that sequence. Custom delivery becomes a candidate if they cannot. It need not replace the help desk: a separate service could prepare an approval packet while the existing application continues handling messages. Keep payment execution outside the scope unless it is explicitly commissioned and controlled.
Ask what you will own when something changes
For every option, name who handles a changed API, rejected case, permission issue, or model update. A software vendor may operate its application while your team remains responsible for the connection to your order system. A custom implementation still depends on its hosting and model providers. Draw the boundary in the agreement.
Test the exit path before signing. Can you export business records, case history, configuration, and evaluation examples in usable formats? Which prompts, workflows, or extensions would need rebuilding elsewhere? Does the contract provide the source access or usage rights your future operator needs? Source-code ownership alone does not make a system portable or maintainable.
Compare the cost of a completed case
Use the same expected volume, review assumptions, and planning period for all options. Include licenses, configuration, delivery, internal time, model usage, support, and migration work. Identify which costs are fixed and which grow with cases, seats, or exceptions. A subscription price and a development quote cover different obligations until those lines are reconciled.
Record the manual work left behind. If employees must copy drafts into another system, resolve mismatched records, or recheck every answer, include that effort. Evaluate a conventional integration or process change alongside AI when the inputs and rules are already predictable.
Fund the next proof, then make the commitment
Use the worksheet to identify the smallest test that could change your choice: a product trial on representative cases, an integration feasibility check, or a custom implementation spike. Define the evidence, owner, and stop condition before paying for the next stage. Choose the option that satisfies the workflow with an operating commitment your team can sustain.
Take this into the conversation
A build-or-buy worksheet for your team.
An editable worksheet for comparing workflow fit, operating responsibilities, cost, and exit requirements.
Download the build-or-buy worksheet (.md)Sources & further reading
Primary documentation for the technical points cited above. The decision frameworks and illustrative examples are PlatformBridge’s editorial guidance.