CustomERPvsSaaSERPinBangladesh:ADecisionFramework,NotaSalesPitch

Every few weeks someone asks us a version of the same question: should we buy an ERP or build one? And almost every time, the question is being asked too early. "Custom or SaaS" is the last decision in the sequence, not the first. The first one is much less exciting: which parts of how you operate are genuinely standard, and which parts are the business?

Get that wrong and the rest follows badly. Companies buy a SaaS ERP to run a process the product has never heard of, then spend two years and more than the licence fee bending it into shape. Or they commission a custom build for accounting, inventory and payroll — three problems that were solved decades ago and that nobody should be paying to solve again.

We build both. That is the only reason this post can be useful: we have no product to defend.

The question that actually decides it

Take your operation and sort every process into one of two piles.

Pile one — standard. Double-entry bookkeeping. Accounts payable. A purchase order approval chain. Fixed asset depreciation. Stock valuation. These work the same way in your company as in a company three streets away, and if they do not, that is usually an accident rather than a strategy. There is nothing to win by building them yourself.

Pile two — the business. The way you price a job. The way an order moves from a WhatsApp message to a confirmed line item. The rules that decide which branch fulfils what. The costing model your industry uses and nobody else does. This pile is the reason customers choose you over a competitor. A generic product will either not support it or support it as a workaround.

If pile two is thin, buy. If pile two is where your margin comes from, a product that cannot express it will quietly cost you more than it saves. Most companies have both piles, which is why most correct answers are not "custom" or "SaaS" — they are a line drawn between the two.

What genuinely forces a custom build here

Some of what pushes a Bangladeshi company toward custom software is universal. Some of it is local, and international products are consistently weak at it — not out of malice, but because it is not their market.

VAT and NBR compliance. Bangladesh's VAT regime under the VAT and Supplementary Duty Act 2012 runs on the Mushak form series — the VAT challan that goes out with a sale, the purchase and sales registers behind it, the monthly return. A global ERP will do VAT beautifully for jurisdictions it was built for, and then leave you generating Mushak documents in Excel from an export. That is not a compliance system; it is a second set of books with a manual bridge. Local statutory output is one of the most common single reasons a company we meet has outgrown the product it bought.

Mobile financial services as a first-class payment method. bKash, Nagad, Rocket and Upay are not a payment integration you bolt on at the end here — for many businesses they are a majority of collections. A product that treats them as "other payment method: cash" will give you a reconciliation problem that grows linearly with revenue. Settlement timing, charges, partial payments and refund flows all need to exist in the data model, not in a comment field.

Bilingual operation. Not translation — operation. Bangla names, Bangla addresses, a printed invoice that a customer can read, staff who work faster in Bangla and managers who report in English. This is a data and typography problem as much as a UI one, and it is usually retrofitted badly.

Import and LC workflow. If you import, your real process runs on proforma invoices, letters of credit, shipping documents, C&F charges and landed-cost allocation across a consignment. Landed cost is the one that hurts: getting it wrong means every margin number downstream is wrong, and generic products tend to model it as a single freight field.

Connectivity that is not guaranteed. A branch, a warehouse floor, a delivery route. Any system that assumes a connection will produce a workaround, and the workaround will become the real process. Offline capture is not a nice-to-have for a branch or a warehouse floor; it is the difference between a system of record and a data-entry queue. It is why WaveHR records attendance locally and syncs when it can.

Paying for it. A USD subscription billed to an international card is an FX and approval exercise for a Bangladeshi company, not a card swipe. Finance teams routinely discover this after signing. It does not decide anything on its own, but it belongs in the cost column, and it rarely is.

The five-year cost model

Sticker price comparisons are where most of these decisions go wrong, because they compare a licence to a project and stop there. Run both sides over five years instead. Use your own figures; the point is the shape, not our numbers.

SaaS, five years

  licence        users x price/user/month x 60
+ implementation partner fees, data migration, configuration
+ customisation  add-ons, scripted extensions, per-change fees
+ integration    connecting the systems it does not replace
+ workaround     staff hours per month on spreadsheets it cannot absorb, x 60
+ exit           what it costs to get your data out in usable shape

Custom, five years

  build          the initial delivery
+ change         12-20% of build per year, in our experience, for a system in real use
+ hosting        infrastructure and monitoring x 60
+ support        the retainer or the in-house time
+ risk           what happens if delivery slips, and what happens if the team changes

Two lines decide most of these comparisons, and both usually get left out.

The first is workaround cost. If four people spend two days a month each reconciling something the system cannot do, that is 96 person-days over five years. Price it. In a surprising number of the comparisons we have run with clients, that single line was larger than the entire licence.

The second is change cost. Custom software is not finished at handover — a system people actually use generates change requests forever, and that is a feature, not a defect. Budget for it or you will experience it as an unpleasant surprise in year two. Equally, "the SaaS vendor handles upgrades" is genuinely valuable and belongs on the other side of the ledger.

So which one?

The honest answer for most mid-sized companies here is a line, not a side: a capable off-the-shelf core for accounting, and custom software for operations. Buy the ledger. Build the thing your business actually is. Make them talk through a real integration with a real owner — not a nightly CSV that someone has to remember to upload.

That split fails in one specific way, and it is worth naming: if the integration has no owner, you do not have two systems, you have two sources of truth. Decide before you start which system owns each entity — customer, product, price, stock — and write it down. Every integration we have been called in to rescue failed on that question rather than on the technology.

Five questions before you commit to either

1. What breaks if this system is down for a day? The answer tells you what tier of reliability you are actually buying, and whether anyone has priced it.
2. Who owns it after launch? A system with no internal owner decays, whichever way you acquired it.
3. Can you get your data out? Ask for an export of one month of transactions before you sign. "Yes, through our API" and "here is the file" are different answers.
4. What is the process you are most proud of? Make the vendor demonstrate that one. Not a generic demo — yours, with your data.
5. What does year three look like? More users, more branches, a new product line, an audit. Price that, not today.

What we would do

If you asked us to decide for you with no other information, we would tell you to buy the standard parts, build the parts that are the business, and spend real effort on the seam between them. That is what most of our ERP work is: not a replacement for everything, but a system that fits the operation, connected properly to the ledger that was already fine.

If you want that assessed against your actual processes rather than in the abstract, tell us what you are working with. We will say plainly if buying is the better answer — it often is, and telling you so costs us nothing we wanted.