What to build in-house versus what to buy

Start with the cost of doing nothing

Before anyone in the room says "we should build this ourselves," it's worth pricing what the current workaround actually costs. Not in software terms, in hours. If three people spend four hours a week reconciling two systems that don't talk to each other, that's roughly 600 hours a year. At almost any wage, that number changes the conversation faster than a feature comparison does.

Ask whether the process is actually unique

Most businesses believe their workflow is special. Most of the time, it isn't; it's a slight variation on a problem a few hundred other companies already solved. The exceptions are real, but they're rarer than they feel from the inside. A useful test: describe the process to someone outside the business without naming your company. If it still sounds specific to you, that's a signal toward custom software. If it sounds like "how most distribution businesses handle stock," that's a signal toward buying.

Off-the-shelf software has a real cost too, it's just deferred

Buying is usually cheaper up front and more expensive over three to five years, once licensing, workarounds for the 20% that doesn't fit, and the eventual migration off the tool are added up. Building is the reverse: expensive early, cheaper later, assuming it's built well and actually maintained. Neither answer is free. The question is which timeline the business can afford.

The honest version of this framework

We use three questions with clients before recommending either path:

• What does the current workaround cost in hours, not opinions?
• Is the process specific to this business, or common to the industry?
• Can this team maintain custom software in three years, or will it become the thing nobody wants to touch?

Sometimes the answer is a custom build. Often, especially for the third question, it isn't. A tool that fits 80% of the need and gets used consistently beats a perfect system nobody maintains.