We build custom software, so the honest place to start is this: most companies should buy something packaged for most of what they do. Payroll rules, basic bookkeeping, email — these are solved problems, and paying someone to solve them again for you is a waste.
The interesting question is not "custom or packaged". It is: which parts of your business are ordinary, and which part is the reason you are still in business? The ordinary parts should be bought. The other part is usually where packaged software fails you, and where building something is worth it.
Here is how to tell them apart.
The test
Take the process you are considering putting into software and ask three questions about it.
Would you change this process to match the software? If the answer is yes — your leave policy, your chart of accounts, the way you file documents — buy the package. Standardising these costs you nothing and saves you a build. Companies that insist on custom software for a process they would happily have changed are paying to preserve an accident of history.
If you changed it, would a customer notice? This is the sharpest of the three. If a dealer, a buyer or a patient would notice and mind, the process is part of what you sell. The credit terms you extend that your competitor does not, the costing method that lets you quote faster, the way your field team handles a returned consignment — those are not inefficiencies to be standardised away.
Has it already been worked around? Look for the spreadsheet. If a process runs on a spreadsheet that somebody maintains by hand alongside the system you already bought, the package has already failed at it, and the failure has a cost you are currently paying in salary and errors. That spreadsheet is the specification for the custom piece.
When off-the-shelf is right
Buy the package when the process is genuinely standard, when there is a mature local option with people who can support it in Bangla, and when the volume is low enough that the software's rough edges do not compound.
Buy it, too, when speed matters more than fit. If you need something running before an audit next month and a package covers seventy per cent of it, take the seventy per cent. You can build the missing part later, once you know exactly what it is — which you will know much better after three months of living with the gap.
There is one more case: when nobody in your company has the time to be the decision-maker a custom build requires. Custom software needs someone on your side who will answer questions weekly and settle arguments between departments. Without that person, a custom project drifts and a package is safer.
When custom earns its cost
Build when the process is the differentiator and the workarounds have already appeared. Build when the data you need lives in three systems that do not talk to each other and never will. Build when the packaged option would force a rule change your customers would notice.
And build when the alternative is paying per user, per month, for something that still does not fit — a calculation that changes sharply once you have fifty people rather than fifteen, and changes again when a system you depend on raises its price and you have nowhere to go.
Ownership matters here and is often underweighted. A custom system on your own infrastructure, with the source code handed to you, is an asset you can move, extend or hand to a different developer. A subscription is an expense you keep paying and a position you cannot leave quickly.
The answer most companies actually land on
In practice, most fifty-person companies here end up with a hybrid: a packaged accounts system the auditor is comfortable with, attendance hardware that came with its own software, and one custom build covering the operational core — the stock, the orders, the production, whichever of those is the business.
That is a perfectly good outcome, and it is worth planning for deliberately rather than arriving at by accident. The thing that makes it work or fail is the connections between the pieces. Decide early which system is authoritative for each fact — which one owns the customer list, which one owns stock, which one owns the ledger — and make sure the others read from it rather than keeping their own copy.
Two systems that each hold their own version of your stock figure is not a hybrid. It is two sets of books.
A practical first step
Write down the five processes that consume the most staff time in a week. Next to each, mark whether you would change it to match software, whether a customer would notice if you did, and whether a spreadsheet is already propping it up.
The ones with a spreadsheet and a customer who would notice are your custom candidates. Usually there are one or two — not five. Start with the one that is costing you the most right now, and leave the rest on the packaged system until it proves it cannot cope.
If you want a second opinion on where that line falls in your business, bring the list to a first conversation. We will tell you which parts we think you should not pay us to build.