Build or buy an internal tool? Count the whole lifecycle

“Build or buy?” often gets reduced to a subscription price versus an engineering estimate. That comparison misses the work around both options: configuration, integration, training, access control, support, data export, and eventual replacement.

Start with the job, not the feature list

Describe the workflow and its exceptions. Which steps are distinctive to the organization? Which are common enough that a mature product may handle them well? A purchased tool is a strong choice when its process fit is good and it reduces undifferentiated maintenance. A custom tool may be justified when the workflow is a product differentiator or the current process crosses systems in a costly, error-prone way.

Compare total operating cost

For a vendor, include licenses, integration, data export, administration, security review, and the cost of adapting the team's process. For custom software, include discovery, delivery, hosting, backups, updates, support, security fixes, and the time needed to keep the system maintainable. Include the cost of changing direction in either case.

Make exit and ownership explicit

Understand who owns the data, how it can be exported, and what happens if the vendor changes terms or the internal team changes priorities. A small proof of concept can test workflow fit, but do not treat a demo as proof that permissions, audit, performance, and support will work at production scale.

Use a reversible decision where possible

• Run a time-boxed pilot with success criteria tied to the actual workflow.
• Keep integrations behind clear interfaces.
• Document the data model and migration path.
• Review the decision after a real operating period, not only at procurement.

There is no universal answer. The best choice is the one that fits the workflow and risk profile while leaving the organization with a clear owner and a credible path forward.