A build-or-buy decision commits the firm to a way of operating. Someone will have to maintain the workflow, manage its access, respond to failures, and adapt it as the business changes. I would compare the options against that continuing responsibility. The useful question is which arrangement gives the firm the capability it needs and an ownership model it can sustain.
Source
The middle options deserve a serious comparison
GDS’s September 2026 purchasing guidance considers combining built and purchased components. That reflects a decision space broader than selecting a vendor or owning an entire application.
I would compare the responsibility left with the firm in each arrangement. A small extension may solve a distinctive handoff, but it also introduces access, dependency, and support obligations. The preferred option should survive that full comparison.
Describe the capability before choosing the product
Start with the people doing the work, the outcome they need, and the constraints that matter. A requirement such as “maintain a reliable record of approvals” is more useful at this stage than a preferred interface or technology stack.
Separate standard needs from the parts that are distinctive. Identity, routine document handling, and common administrative workflows may fit established products. A firm-specific handoff or a narrow integration may justify a smaller custom component. Confirm that distinction through actual workflow observation.
Include the option to defer or simplify the request. If the workflow is still changing quickly, a bounded manual process can help the team understand it before making a larger commitment.
Compare several ways to deliver it
The options usually include buying a product, configuring something already owned, extending a platform, and building a standalone tool. Put each against the same requirements and acceptance conditions.
The UK Government Digital Service’s purchasing guidance considers build, buy, and combined approaches alongside capability and continuing management. Those decision principles are useful here; the public-sector procurement rules are a separate context.
Compare delivery effort, access controls, integration work, support, change, and exit. A subscription price is one input. So are the time required to configure it, the limits of its export, and the burden created when the workflow does not quite fit.
For a custom option, include software maintenance, dependency changes, recovery, and security work. NIST’s Secure Software Development Framework helps make the software lifecycle visible beyond the initial implementation.
Test the assumptions that could change the answer
A hypothetical approval process might fit an existing platform except for one transfer into the relationship system. A narrow integration could be enough. If the platform cannot represent the required permissions or history, that same approach may leave a fundamental gap.
Test those decisive requirements early. Ask for a real export. Walk through an access change. Have another person operate the prototype. Examine what happens when an integration fails after only part of the work is complete.
Use ranges for uncertain effort. Ask how the decision changes if maintenance is greater than expected, a provider changes its interface, or the workflow doubles in scope. The point is to expose fragile assumptions, not to produce a universal weighted score.
Proposal
Record what the firm is agreeing to own
A short decision memo should identify the selected arrangement, the reasons, the remaining limitations, and the operating owner. Include the evidence from the pilot and the conditions that would justify reconsideration.
State the exit path while the decision is still being made. Who can export the data? What must be rebuilt elsewhere? How will the previous workflow be retired?
The best choice is the one that fits the required capability and a sustainable ownership model. Its value should remain understandable after the person who made the original recommendation has moved on to something else.
Proposal
What I would test next
I would test the requirement most likely to reverse the decision: a difficult permission rule, a usable export, or an integration failure. Compare the options again with that evidence and a named operating owner.