Build, buy, or integrate: a decision record for software teams

Choose whether to build, buy, or integrate software by comparing the work your team would own under each option. A feature comparison is incomplete. The decision also depends on who maintains the business rules, handles failures, and gets the data out when requirements change.

Record the decision while those assumptions are visible. Six months later, a short explanation of why an option was chosen is more useful than a spreadsheet full of unexplained scores.

Compare the same business capability

Define the required workflow before evaluating products. Separate mandatory constraints from preferences: required permissions, integration events, supported languages, data export, and acceptable downtime need explicit answers.

Building offers control but leaves delivery and ongoing operation with your team. Buying can fit a standard process but still requires configuration, migration, and vendor management. Integrating combines systems while adding a boundary someone must operate. These options overlap: buying the core and building a narrow extension is often a distinct candidate worth evaluating.

Do not count a vendor’s roadmap promise as a currently supported capability. Mark it as a dependency with an owner and a fallback.

Write a decision record people can challenge

AWS’s guidance on architectural decision records identifies context, decision, and consequences as the minimum contents. Use that structure for the build/buy/integrate choice, and add the evidence needed to revisit it.

Record field	What to capture
Problem	The work and users the decision serves
Constraints	Requirements that can disqualify an option
Candidates	Realistic build, vendor, and combination options
Ownership	Who changes rules and responds to failures
Evidence	Trial results, documented limits, and unresolved assumptions
Revisit trigger	A concrete change that would invalidate the reasoning

Use rough estimates consistently, with assumptions stated. Subscription cost should not be compared only with initial development cost. Include migration, integration maintenance, support effort, and eventual replacement without pretending those estimates are precise forecasts.

A hypothetical service operations tool

Imagine a bilingual operations team choosing a scheduling system. A vendor handles ordinary assignments well but cannot represent the team’s approval rule. A full custom build would fit that rule but also require rebuilding ordinary scheduling functions.

The team evaluates a third option: buy scheduling and build a small approval service. In the hypothetical trial, it checks whether the vendor exposes stable assignment IDs, events, and an API that can enforce the approved state.

If users can bypass approval inside the vendor interface, the integration may fail the mandatory workflow even though data synchronizes correctly. The decision record should say that plainly. A working API connection is not proof that the combined process works.

Test the exit before signing off

Ask for an actual export and inspect whether it includes relationships, attachments, and identifiers needed for migration. Try a permission change and an integration interruption. Establish who resolves disagreements between systems rather than assuming one is always correct.

Choose a small proof exercise that could disqualify the preferred option. For the scheduling example, test the approval boundary before polishing dashboards. Bring the resulting decision record into custom software development planning so the scope reflects the work worth owning, not an automatic preference for building everything.