Build vs. buy: decide one workflow at a time

The build-or-buy decision usually contains several smaller decisions. A company can use established software for its core records and build a tool that connects those records to a process of its own.

It helps to separate those choices before comparing vendors or estimating development time.

Where established software helps #

Payroll, identity, email, and other common business functions come with requirements that extend well beyond the first working version. Updates, support, integrations, and ongoing maintenance belong in the comparison.

Buying software can make sense when its existing behavior fits the work closely enough and your team can operate it without extensive customization.

Where a custom tool may fit #

Some workflows depend on decisions, data, or customer requirements that are specific to your business. Examples include an internal approval process, reporting across several systems, or a customer experience that is part of the product itself.

A custom tool may be a good fit there. The comparison still needs to include testing, documentation, support, and the people who will maintain it. A quick prototype does not tell you the full cost of running the system.

The example behind this comparison was a workflow covered by a $90K annual vendor contract. It could be handled by a roughly 400-line internal tool with about half a day of engineering maintenance each month. That comparison depended on the particular workflow and its requirements; it is not a budget estimate for another company's project.

Compare the whole job #

For each workflow, describe what must happen, what can be configured in an existing product, and what would need to be built. Include the cost of moving data and the work required if you later change direction.

The answer for marketing automation may differ from the answer for invoice processing. Make each decision against its own requirements, then check how the choices work together.