Almost every first conversation with a new client arrives here. Buy or build. And because we are a software company, most people expect us to say build. We do not. We recommend the standard product more often than our sales pipeline would like.
The reason is dull. For most of what a company does, off the shelf software is simply the better choice, and not by a small margin. It only gets interesting at the edges. That is where the real decision sits, and it deserves more than a gut feeling.
Where standard software almost always wins
Accounting, payroll, time tracking, statutory reporting. Anything the legislator regulates changes for you exactly as it changes for your competitor. Build it yourself and you are reimplementing the law, then maintaining that reimplementation every year when contribution rates or filing formats move again. Vendors do this work once and ship it to tens of thousands of businesses. Taking it on in house buys you no advantage. It buys you a maintenance bill.
The same goes for the ordinary parts of a merchandise management system. If your process runs the way it runs in a thousand other firms, buy it. And if it runs differently only because someone built a spreadsheet twelve years ago, that is not a process. That is a habit.
Where building your own genuinely pays off
Two situations, in our experience.
The first: the process itself is your advantage. You cost jobs differently than the rest of your industry, you schedule differently, you have a production logic you refined over years and it is why customers pick you. A standard product is not neutral here. It pushes you back toward the average, because the average is what it encodes. You would be paying to sand down your own edge.
The second: the standard fits only after so many modifications that you end up with custom software anyway. Just not custom software you own.
The most expensive route
"We will take the standard and adapt it a little" sounds like the sensible middle. In practice it is often the priciest option on the table.
You pay the licence. You pay for the customisation. Then you pay again at every update, because your modifications hang off parts the vendor changes without a thought for you. After a few release cycles the upgrade looks too risky to attempt, so you stop upgrading. Now you sit on a version nobody supports properly, with no clean migration path, and the consultant who understood your modifications moved on to another client long ago. You have custom software with somebody else's maintenance contract.
Four questions that carry the decision
How special is the process, really? Not how special it feels. Ask two people in your industry how they do it. If the answers differ only in detail, you are in standard territory.
How often does it change? A process you rebuild twice a year because your market moves will need a consultant every single time inside a rigid product. In software you own it is a manageable development ticket.
Who owns the data in the end? If it came to it, could you get everything out, in a format another system can read? Few people ask this before signing. Almost everyone asks it after cancelling.
What does leaving cost? Work it out before you go in. Licence commitments, migration, retraining, running two systems side by side. If the exit is unaffordable, the entrance is a one way street.
Custom software comes with duties
Honesty demands this part. Software you own is software you maintain. Libraries age, security holes turn up, operating systems move on, and one day somebody has to answer the question of who still understands the code. Commission a custom development project, invest nothing for five years afterwards, and you end up with exactly the legacy system you were trying to escape. That is not an argument against building. It is an argument for budgeting the follow up cost from day one.
Frequently asked questions
Can we combine standard and custom software?
Yes, and it is often the right answer. Accounting and payroll from a product, your core process in software you own, a clean interface in between. What matters is that the interface gets designed at the start rather than bolted on once the pain shows up.
How big does a company need to be for custom software to make sense?
Size is the wrong measure. A firm with eight employees can have one process that carries the entire business and no product covers it. A large group can happily buy its standard processes off the shelf. The question is whether the process is your business.
What if we choose wrong?
Then it matters how expensive the way back is. Which is why the exit question sits near the top of the list and not at the bottom.
If you are facing this decision and want an assessment that does not depend on what we could sell you, write to us. We will look at your process and tell you plainly when the standard is enough, no obligation and no sales pressure.
This article is part of our knowledge hub Custom software development.