When custom software is the right answer, and when it isn't

Custom software is expensive to build and more expensive to abandon. Yet companies commission it for the wrong reasons all the time: a vendor demo went badly, a competitor announced a platform, or a spreadsheet finally broke. The decision deserves a framework, and this is the one we use.

Start with the workflow, not the tool

Write down the workflow in plain language: who does what, in what order, with which information, and what happens when something goes wrong. Most of the value of this exercise is discovering that the workflow is not agreed on. Until it is, no software will fix it.

Three honest questions

First: is this workflow a source of competitive advantage, or just a cost of doing business? Payroll is a cost; buy it. The way you quote complex jobs or route orders might be an advantage; that is a candidate for building. Second: how many people touch it, how often, and what does each error cost? A process that three people run monthly rarely justifies custom code. One that fifty people run hourly almost always does. Third: what does the best off-the-shelf tool fail to do, specifically? If the answer is a list of configuration gaps, configure. If the answer is 'it does not understand our business model', build.

The middle path most companies miss

Between buying and building there is integration: keeping the tools you have and adding a thin layer that connects them, enforces rules and gives everyone one view of the data. It is often the fastest way to remove the pain, and it teaches you exactly which parts deserve a custom build later.

What a good build looks like

If you do build, insist on three things. The code lives in your repositories and your cloud. The first release ships within weeks and is used by real people. And the team agrees up front how success will be measured, so the second phase is justified by evidence rather than momentum.