Build or Buy an Internal Tool?

The decision is not custom software versus an off-the-shelf feature list. It is the total cost of fitting a product to the real process, including integration, data ownership, workarounds, and future change, compared with a scoped build and its operating obligations.

Identify the differentiating work

Write the few decisions that make the process unusual. If an existing product supports them through configuration, buying may be faster. If workarounds dominate daily operations, custom software deserves evaluation.

Map data and exits

Ask where records live, how they are exported, whether APIs cover important actions, and what happens if the vendor changes pricing or closes an integration.

Estimate both operating models

A custom tool needs product ownership, security, hosting, and maintenance. A purchased tool needs administration, training, vendor monitoring, and sometimes ongoing integration work.

Compare exceptions in a short trial

Give each option the same small set of representative work: a routine case, a changed request, a duplicate, a reversal, and a reporting question. Note which steps require manual exports, copied identifiers, administrator intervention, or vendor support. A purchased product may handle the routine case quickly yet create daily reconciliation work around an unusual but important rule. A custom prototype can expose whether that rule is stable enough to encode. Record the operator time and error risk for each path, not only whether a feature appears on a sales sheet.

Build a comparison sheet from actual tasks. Rows can be routine entry, exception handling, permissions, reporting, integration, export, outage recovery, and change requests. For each candidate, record the demonstration result, manual workaround, owner, and an estimated operating cost over several years. Keep unverified vendor answers marked as assumptions until a pilot confirms them. Add the custom-build prototype to the same sheet, including hosting and support obligations. This avoids comparing a polished purchased demo with an unrealistically free custom build. The recommendation can then point to the few constraints that truly determine the choice.

Budget for ownership after launch

For a product, identify who manages configuration, permissions, renewal, integrations, and support tickets. For a custom tool, identify who owns requirements, security updates, hosting, monitoring, and changes when the process evolves. In both cases, plan data export, documented identifiers, and a fallback when the system is unavailable. A decision memo should state the assumptions that would change the recommendation, such as volume growth, a vendor price change, or a new regulatory obligation. That makes the choice reviewable later instead of treating it as permanent.

Decision checklist

• List the top five tasks users perform each week.
• Score each candidate against exceptions, not marketing features.
• Prototype one difficult workflow in both approaches.
• Include migration and exit in the comparison.

A small test before committing

Select one difficult weekly task and give both a product candidate and a small custom prototype the same inputs, roles, and exception. Time the work, count duplicate entry, and record which rules need a workaround. Then price administration, integration, hosting, maintenance, and exit over the expected life of the tool. If the purchased product handles the exception through ordinary configuration, a custom build may have little advantage; if the workaround is daily, investigate a focused build.

Worked scenario

A hypothetical dispatch team may find that a standard scheduler handles appointments but cannot represent equipment dependencies. If that rule causes repeated manual rework, test whether configuration solves it before commissioning a new platform.

For a scoped application of this decision, see Custom Software Engineering.