The question is almost always asked one size too large. Whether a company needs off-the-shelf software or an application of its own cannot be answered, because no company has only one process. The question becomes useful only when you point it at a single workflow.
Payroll is essentially the same everywhere. The way a supplier schedules its production orders is not. For the first there are excellent products; for the second, rarely one that fits.
When standard software is the better choice
Four signs point that way fairly reliably.
The process is ordinary. Accounting, payroll, time tracking, sending newsletters. Thousands of businesses do this in much the same way, and somebody has already solved the problem more thoroughly than it would ever pay you to solve it alone.
The changes you need are settings. An extra form field, a different report header, one more role. As long as the adjustment is foreseen by the product, it survives the next update.
The process gives you no advantage of your own. Nobody buys from you because your expenses process is better. Where everyone does the same thing, building your own is mostly just dearer.
It has to be quick. A product is there on Monday. An application takes weeks even in its smallest sensible form.
When building your own pays off
There are equally clear signs that a finished product will cost more over time than an application of your own.
The workflow is particular to you. If the answer to “why do you do it that way?” is a story about your market rather than about missing software, no product will represent it without you bending to fit.
Other systems have to join in. As soon as stock control, warehouse, machines, portals and the shop are meant to work together, the connection becomes the actual subject. Finished products are weakest exactly there, because each treats its own world as the whole one.
The rules change at your pace. If a pricing rule is reworked twice a year, you need somebody who can implement that without waiting on a vendor’s roadmap.
The data should stay with you. Not as a matter of principle but a practical one. How do you get hold of everything if you want to change supplier? An export in a readable format is a good answer. A quotation for a migration project is not.
The expensive middle road
Things most often go wrong where a standard product is customised until it is a one-off. You then have the drawbacks of both sides. The changes depend on one supplier, the update arrives anyway and breaks half of them, and the vendor supports a variant that exists only once.
A usable test: when the customisation costs more than the licence, it is no longer a standard product. At that point the route should be chosen deliberately rather than drifted into.
What it really comes down to
Not the size of the company. A business of thirty people can have a workflow so particular that only a custom build fits, while a corporation settles its travel expenses in a standard product.
It comes down to how particular the process is and how long it has to last. A process that will look different in two years suits a product with a notice period better than a custom build. A process that has carried your business for twenty years deserves an application that belongs to you.
If you are unsure which case you are in, a software audit or a consulting engagement is the cheaper first step. If the decision is already made, Laravel development describes how a project like this runs with us.
