A software proposal should explain more than what will work at launch. Before approving it, require answers about who keeps the workflow running, who pays when requirements change, and how the business could leave. Without those answers, the operating commitment is still undefined.
For a non-software company, a build-versus-buy decision should weigh workflow fit against the responsibilities the organization can sustain. The framework below compares buying, custom building and combining them. It is an editorial decision aid, not a validated scorecard: its evidence comes mainly from government purchasing guidance and enterprise-software research, not comparative outcomes across non-software businesses.
Start With the Workflow and Its Consequences
Trace the work from trigger to completion: handoffs, approval paths, exceptions and controls. Identify where delay, error or system unavailability would threaten continuity. Separate requirements that protect business outcomes from preferences about how the current process looks.
For each claimed differentiator, ask what business value would be lost by adopting a product’s standard workflow. Keep mandatory controls distinct from habits the business is willing to change. Give configuration a fair test where process changes are acceptable; investigate custom development where an essential requirement remains unmet. Uniqueness alone should not settle the choice.
Compare Three Options and Their Responsibilities
GOV.UK’s government technology purchasing guidance explicitly includes build, buy and combined approaches. Use that option set without presuming that combining them is preferable. Define each candidate by what you acquire and what you must continue to own.
Verify configuration limits and support scope. Assign ownership of adoption, data and vendor management.
Assess internal or commissioned delivery. Assign product, architecture, maintenance and security ownership.
Define each component’s role. Assign interface maintenance, compatibility and cross-component incident responsibility.
Editorial comparison. Assess each option’s responsibilities rather than assuming one carries less risk.
Compare the acquisition and retained responsibilities for each option.Treat outsourced custom development as a build, not as buying a supported product. Assess ongoing support separately from delivery. Specify who sets priorities, approves architectural changes and funds maintenance after acceptance. For a combined approach, also name who resolves problems that cross the product and custom-code boundary.
Use a Lifecycle Decision Matrix
GOV.UK recommends assessing requirements, market availability, full build-or-buy cost, product lifecycle and organizational capabilities. Transfer that government purchasing discipline to the comparison, not an expectation that any option will deliver better outcomes.
A June 29, 2026 arXiv preprint on enterprise software suggests that explicit, systematically comparable criteria may improve decision quality, transparency and auditability. Study design, sample and effect sizes were not available in the reviewed passages. That offers a cautious rationale for structured comparison, not validated scoring weights or approval thresholds.
Custom build: Define essential bespoke behavior. Combine: Bound the work requiring custom behavior.
Custom build: Specify interfaces and authoritative records. Combine: Assign boundary and transfer-failure ownership.
Custom build: Assign development and operational controls. Combine: Assess both components and their connection.
Custom build: Identify design, delivery and acceptance work. Combine: Identify component and integration dependencies.
Custom build: Examine initial work, maintenance, security, on-call and team opportunity cost. Combine: Include both components and interface upkeep.
Custom build: Allocate product and technical oversight capacity. Combine: Allocate coordination capacity across both.
Custom build: Assign fixes, upgrades and incident response. Combine: Assign compatibility and cross-component incidents.
Custom build: Review dependence on developers and specialist knowledge. Combine: Review dependencies on both sides.
Editorial aid, not a scoring model. Cost prompts draw on DIIGOO’s practitioner framing, not independently validated estimates.
Compare each criterion across buy/configure, custom build and combine. Replace prompts with candidate-specific answers, evidence and unresolved questions.Verify usable exports, termination terms and transition assistance.
Verify rights, documentation and another team’s ability to take over.
Identify what must change when either component is replaced and who maintains continuity.
Editorial prompts. Record untested exit assumptions rather than treating portability as established.
Compare exit requirements explicitly for all three options.Create a working column for each actual candidate. Record the evidence, uncertainty and responsible owner beside each answer. Agree mandatory requirements before comparing preferences, and do not let attractive features silently compensate for a failed control. For time to value, compare the path to an agreed operational acceptance point rather than a purchase date or code-completion milestone.
Test Integration, Security and Exit Early
Require more than a statement that an integration exists. Identify the authoritative record, what crosses each boundary, who can change it, and how failed transfers will be detected and recovered. Demonstrate the priority path with representative, appropriately protected data, including a consequential exception.
NIST’s guidance for U.S. federal software procurement helps agency staff determine what information to request from producers about secure software-development practices. Apply that narrow discipline by requesting relevant supplier information for review. The guidance does not establish a complete private-sector security framework. Have your security or risk owner separately define the workflow’s required controls and assess each option against them.
For exit, inspect a representative export for usable structure and necessary context. Review contractual rights, access to custom code and documentation, transition assistance and migration responsibilities. State what would be needed to keep the workflow running during a change. A successful export is evidence about that test, not proof that a full transition will be straightforward.
Budget for the Work After Launch
DIIGOO’s practitioner framework frames buying costs as licenses, integration, per-seat growth and eventual migration. It frames building costs as initial work, maintenance, security, on-call responsibility and team opportunity cost. These are practitioner categories, not independently validated cost estimates. Use them to challenge omissions, not calculate a predetermined winner.
GOV.UK’s lifecycle guidance also includes upgrades, continuous improvement and retirement. Compare candidates over the same planning period, with assumptions and exclusions visible. Do not treat the cost categories as exclusive: examine retained security and operating work for a purchase, and third-party services or licenses for a build. Include interface upkeep for a combined solution.
Name one business owner accountable for workflow outcomes. Separately assign incident response, change approval, integration maintenance, supplier management and retirement planning. Check whether the assigned people have capacity, and identify what other work would be displaced. Where a supplier performs the work, specify who verifies it internally and authorizes expenditure. An unassigned responsibility belongs on the unresolved-commitments list, not in a zero-cost line.
Validate the Riskiest Assumptions Before Committing
Choose validation work by the consequence of being wrong. Before starting, define the question, scope, acceptance conditions and reviewer. Set a time and resource limit appropriate to that question. The following sequence is editorial guidance informed by purchasing, supplier-information and explicit-criteria guidance, not a validated pilot method.
Agree priority paths, exceptions, mandatory controls and acceptable process changes.
Test selected integration, data-handling and export assumptions. Record what remains untested.
Have a qualified reviewer assess relevant security-practice information and support terms.
Document owners, capacity and funding assumptions for operation, improvement and retirement.
Compare candidates against the matrix. Name the decision owner and document accepted risks.
Use question-specific acceptance conditions. There is no universal duration, score or approval threshold.
Define the workflow, test consequential assumptions, assign lifecycle work and record the decision.The approval record should explain why the selected option fits, which compromises the business accepts, who owns them and what would trigger reconsideration. Apply the same standard to a supported product, a custom build and a combination. If a high-consequence assumption remains unresolved, resolve it or narrow the commitment before approval. Approve only the operating responsibility the business is prepared to fund and own.
