Configure, buy, integrate or build? A guide

Verdict in one line. Configure what you already own first, buy when a packaged tool covers the whole gap, integrate when the gap sits between systems, and build only what is left. Three common versions of this choice have their own page: deductions software or a redesign, an order capture tool or an order-flow redesign and your CDE’s AI or a connected record.

When an operation is slow, the first instinct is to pick a tool. That is the wrong first move. The better first question is a sourcing one: for this process, which parts can be handled by something you already own, which by something you could buy, which need connecting to your systems of record, and which are a real gap that justifies custom work?

This article gives a CIO, a security stakeholder and a process owner a way to answer that for one operating process. It is about where the capability comes from and who owns it afterwards. It does not decide which steps need AI and which should be plain rules; that is a separate logic choice covered in AI or deterministic automation: a decision matrix.

Five options, defined narrowly

Most sourcing debates stall because “build” and “buy” are used loosely. Here are the terms used below.

These are not exclusive. Microsoft’s own guidance on the question describes a spectrum: start with a ready-made tool, extend it with low-code, and move to custom development as needs grow, and it states that the approaches are not mutually exclusive. That is vendor guidance, written by a company that sells products at each point on the spectrum, so treat it as a useful vocabulary rather than neutral evidence about which path wins.

Start with the operating problem

A sourcing decision made before the process is understood is a guess with a purchase order attached. Before comparing options, write down:

1. The outcome and the baseline. What is slow, wrong or costly today, measured how, over what period? If you cannot state it, you cannot tell whether any option helped.
2. The path. What enters, who decides, which system is authoritative, where work waits, and what happens when the normal route fails.
3. The decision rights. Which decisions are consequential enough that a named person must approve them regardless of tooling?
4. The constraints. Data location, permissions, audit duties, regulatory exposure, existing contracts and available skills.

Microsoft’s AI strategy guidance makes a similar point for its own audience: begin with business problems and the activity and result you expect, then choose the technology. It also lists four factors for weighing a solution: capabilities, the data needed, the skills required and cost. Those are sensible for any vendor, not only Microsoft.

A decision matrix you can fill in

For each stage of the process, rate how well each option fits. The point is not to add up a score; it is to expose where the real disagreement is.

Microsoft’s strategy page states the same trade in its own terms: moving from ready-to-use options toward infrastructure gives more control and costs speed, and each step requires more technical skill and operational ownership. The matrix above generalizes that trade beyond one vendor, but the ratings are judgment, not measured data. Replace them with your own evidence.

Questions that move you between columns

Work through these in order. Stop at the first “yes” that settles a stage.

1. Does a tool we already license cover this stage on real data, with real permissions? If yes, configure it and measure. Test with your own documents, exceptions and edge cases, not the vendor demonstration.
2. If not, does a packaged product cover the full path, including exceptions? Ask to see the failure path, not the happy path. If yes, buy, but price the integration and ownership costs, not only the license.
3. Does the stage need data or actions from systems of record? Then you are integrating, whichever option you chose above. Identify the system of record, use supported interfaces, give service identities least privilege, bound what automation may write, and keep an approval point for consequential actions.
4. Is there still a gap that is both material and distinctive? Build only that, as a bounded component with tests, documentation and a named maintainer. Do not build a platform to host one step.
5. Is the real problem a decision right, a handoff or poor data entry? Then the answer is a process change first.

What a CIO or security reviewer should ask of any option

Whichever column wins, the diligence questions are similar. NIST’s generative AI profile (voluntary guidance, not a certification) recommends, among other things, updating due diligence when acquiring generative AI, inventorying third parties that have access to organizational content, defining who owns incident response for third-party technologies, and addressing incident response and response times in vendor service agreements. Translated into sourcing questions:

• Inventory: which third parties, models and data stores would touch this process, and who holds the list?
• Permissions: what can each component read and write, and can that be limited per action?
• Failure and recovery: what happens when a component is unavailable, wrong or changed? Who is called, and what is rolled back?
• Audit: can you reconstruct who or what decided, on which evidence, and with what outcome?
• Ownership: who owns monitoring, change control, incident response and the contract?
• Exit: can you export your data and configuration, and what would replacement involve?

If an option cannot answer these in writing, that is a finding, whatever the demonstration looked like.

A synthetic example

The following is illustrative and invented; it describes no client.

A mid-sized distributor’s finance team spends hours reconciling customer remittance advice against open invoices. They consider four routes.

• The ERP already has a rules-based matching feature. Configure it first for exact matches and known customer reference formats.
• A packaged cash-application product might handle the remaining matches, but its trial shows weak handling of partial payments with deductions. Buy is parked until that exception path is tested on the company’s real remittance files.
• Unmatched items require bank data, ERP records and customer correspondence. That is an integrate question: which interfaces are supported, which identities may read what, and where a human approves a write-off.
• A custom component for reading unusual remittance formats might be justified, but only after the first three are tested. Build is limited to that one gap, with a named maintainer.

The outcome is a mixed answer, which is normal. Different stages source differently, and the decision record names an owner, a test and an exit path for each.

Failure modes to design against

What this does not prove

This article offers criteria and a vocabulary. It does not show that any option is cheaper, faster or safer in general; the cited guidance is vendor or voluntary-standards material, and the example is synthetic. It makes no claim about which products currently support which integrations, and any such fact must be checked against current documentation before you rely on it. Sourcing outcomes depend on your systems, contracts, skills and risk appetite, and a decision record is only as good as the testing behind it.

Where Sembium fits

Sembium works on whole operating processes: analysis, redesign, integration, adoption and measurement, with deterministic rules for known paths, bounded AI where interpretation helps and accountable people for consequential decisions. In that setting, sourcing is one design decision inside a program, made after the baseline and before the build. See the approach for how a program is staged, and what an agentic operating layer is for what sits across the sourcing choices once you have made them.

Got a bottleneck that costs you $1M or more, and you want it solved? Book the 30-minute bottleneck call. Bring one process. You leave with one practical recommendation and a clear answer on fit.