Custom Software: Build, Buy, or Neither

The question is usually asked backwards. Owners ask whether they are big enough for custom software, when size is not the deciding factor. A twelve-person shop with an unusual quoting process may need something built. A two-hundred-person company doing ordinary work across ordinary departments probably does not.

What matters is whether the way you work is an advantage or just a habit. If your estimating method wins you jobs your competitors cannot price, that is worth protecting in software built around it. If your process is unusual only because nobody ever standardized it, the better move is to adopt a platform and change the process.

The second test is the cost of compromise. Every off-the-shelf product forces some adjustment. That is normal and usually fine. It stops being fine when the workarounds multiply into a shadow system of spreadsheets, re-keyed data and one person who knows how it all fits together. At that point the platform is not saving money, it is moving the cost somewhere harder to see.

We would rather tell a client to buy a product and configure it properly than sell them a build they did not need.

Build or buy is rarely settled on features. Feature lists look similar on every vendor's site, and a demo is designed to survive comparison. The decision is better made on three things: fit, control and exit.

Fit is not whether the product can do what you need. It is how much of your work has to change to match it, and whether that change is an improvement. Sometimes it is. A company that adopts a proven platform often inherits a better process than the one it had.

Control matters when a system touches the part of the business customers actually notice. If your quoting speed, your lead times or your customer portal are why people choose you, renting that capability from a vendor means your advantage moves at the vendor's roadmap speed rather than yours.

Exit is the test most companies skip. Ask what happens in three years if the product is acquired, repriced or discontinued. Where does your data live, in what format, and how hard is it to leave.

The usual answer is a mix. Buy the accounting, buy the email, buy the CRM if a standard one fits. Build the piece in the middle that connects them and holds the process nobody else runs the way you do.

Nobody can price custom software from a description, and a firm that quotes one on a first call is either guessing or protecting itself with a number large enough to cover the guess.

Three things move cost more than anything else. The first is how many other systems it has to talk to. A tool that stands alone is straightforward. A tool that reads from an accounting package, writes to a CRM and pulls pricing from a legacy database carries most of its cost in those seams, not in the software itself.

The second is how many kinds of user it serves. One role doing one job is simple. Sales, production, finance and an outside customer each seeing a different view of the same data is a different project.

The third is the state of your data. Clean, consistent records in one place are a starting point. Data spread across spreadsheets with three spellings of every customer name is a migration project before it is a software project, and that work is real.

The useful move is a paid discovery phase before committing to a build. It costs a fraction of the project, it produces a specification you own, and you can take that specification to anyone. If discovery concludes that you should buy a platform instead, the money still did its job.

Software timelines fail in predictable ways, and none of them are technical surprises.

The most common is decision latency. A build moves at the speed of the answers it needs. When a question about how pricing works waits two weeks for the one person who knows, the schedule absorbs those two weeks and never gets them back. Naming someone who can decide, and who is actually available, does more for a timeline than adding developers.

The second is data. Every project assumes the existing data is roughly in order. It usually is not, and the cleanup is discovered rather than planned.

The third is scope. New requests during a build are a good sign, because they mean people can finally see what they are getting. They are also how a four-month project becomes an eight-month one. The fix is not to refuse them. It is to park them for a second release and protect the first.

We would rather put a narrow, working version in people's hands early and extend it than disappear for a year and return with something nobody has used. Software that has been in real use for a month tells you more than any specification.