The default is usually to buy

When a team needs a new tool — to track requests, manage inventory, handle approvals, or report on operations — the instinct is to search for existing software. There are good reasons for this: faster setup, no engineering required, and someone else handles infrastructure and updates. For many use cases, this is the right call. But the decision is often made by default rather than by deliberate evaluation, and that leads to teams stuck with tools that do not quite fit.

Signs that off-the-shelf is not working

A few patterns indicate that a bought tool is becoming a liability rather than an asset: Workarounds have become permanent. If your team has a spreadsheet that lives alongside the software to fill in gaps, that is a sign the software is not actually covering the workflow. The tool does things you do not need, but cannot do things you do. Generic platforms optimise for the average user. If your operations are specific enough, the trade-offs in a generic tool will start working against you. Training is constant. If every new team member requires significant time to learn the tool, that is often a sign the interface does not match how your team actually thinks about the work. Data lives in multiple places. If you have to export from one tool, transform in a spreadsheet, and import into another to get a report, you are paying for the integration work with staff time. If several of these sound familiar, here are the signs worth checking against directly.

When building makes sense

Building an internal tool is worth considering when:

• The workflow is specific enough that no existing tool covers it well
• The cost of the workarounds (staff time, errors, friction) exceeds the cost of building
• The tool will be used frequently by multiple people
• You need control over the data — what is stored, how it is accessed, who can see it

The bar is not perfection. A focused internal tool that covers 80% of your workflow cleanly is more valuable than a platform that covers 100% awkwardly.

What a good internal tool actually is

Internal tools are not mini-apps with elaborate features. They are focused interfaces that make a specific workflow faster and less error-prone. The best ones:

• Match how your team already thinks about the work
• Surface the right information at the right time
• Reduce decision-making overhead
• Are maintainable by someone other than the original builder

Simplicity is a feature. An internal tool that does fewer things but does them well will be adopted and trusted. One that tries to do everything will be avoided.

The hybrid approach

In practice, many teams end up with a combination: a bought platform for standard operations, and a custom layer built on top for the parts that do not fit. This can work well when the integration is clean and the custom layer has a clear scope. It tends to fail when the custom layer grows to compensate for more and more gaps in the platform, eventually becoming harder to maintain than a purpose-built system would have been. The key is being honest about where the platform ends and the custom work begins, and making that decision deliberately.

The question to ask before deciding

Rather than asking "should we build or buy?", the more useful question is: "what would it cost us to live with the current friction for the next two years?" If the answer is significant — in staff time, in errors, in missed visibility — the calculus for building shifts quickly. If you get to the point of wanting real numbers rather than a framework, see how much custom software actually costs in Phuket.