Where renting an ERP stops being cheaper than owning one

"Should we buy an ERP or build one?" is not answerable, because it is two questions wearing one coat. The first is arithmetic: at your headcount, over the period you actually plan for, which total is smaller. The second is fit: does an off-the-shelf system already do the thing your business is billed on. The arithmetic is easy and almost nobody does it. The fit question is hard and almost everybody answers it with a demo.

This page does the arithmetic in full, with every input named and sourced, so you can substitute your own numbers. Then it says plainly when off-the-shelf wins, because a costing page from a company that builds custom software is worthless if it only ever arrives at one answer.

One thing to fix before you start: the period. A subscription compared over twelve months always looks cheap, because the whole point of a subscription is that the pain is deferred. Compare over five years. Five is not arbitrary — it is roughly how long a working business system stays in service before it is either replaced or substantially rebuilt, and it is long enough that the recurring side of the comparison stops being rounding.

Odoo publishes its prices, which makes it the honest anchor for the category. Odoo's own pricing page lists Standard at USD 16.90 per user per month on annual billing and Custom at USD 25.50, with a note that the discount applies for twelve months on the initial users ordered, and with Odoo.sh hosting excluded from the Custom figure. At USD 1 to RM 4.09, the rate in August 2026, that is roughly RM 69 and RM 104 per user per month. Odoo prices by country, so confirm your Malaysian figure rather than trusting this conversion.

Kladana is worth looking at because its ladder makes the per-user model visible. Its published plans include one user on Free and Start, two on Growth, five on Business and ten on Business Plus, with additional users as a paid add-on. That is the shape of the whole category: the price is a function of how many people you let in, which means the system quietly rewards you for keeping people out of it.

HashMicro takes the opposite position and does not publish a number at all. Its Malaysian ERP page states unlimited user licences at no additional cost per user, and pricing is by quotation. That is a genuinely different commercial model and a real advantage for a business with many light-touch users, but it also means you cannot compare it on a page like this one. You have to get the quote and then run the same five-year arithmetic against it.

For the local market as a whole, SMURPS puts cloud ERP in Malaysia at RM 100 to RM 500 per user per month depending on how many modules are switched on. That range is a factor of five wide, and the factor of five is the single biggest reason two businesses reach opposite conclusions from the same comparison.

Nothing clever here — the monthly price multiplied out. It is on the page because the multiplication is the step people skip, and because seeing RM 104 a month land at RM 124,800 for a twenty-person team is the moment the comparison starts to feel real.

The first two rows are Odoo's published US prices converted at RM 4.09. The last three are points inside the RM 100 to RM 500 band SMURPS publishes for Malaysian cloud ERP.

A build has three costs and only the first one gets quoted. Our published floor for H.E.L.M is RM 25,000 one-time for a core deployment: operations, invoicing and accounting on one ledger, with roles, audit trail, data migration and training. It is a floor rather than a price, and the scope decides where above it you land.

The second cost is infrastructure, and it is smaller than people expect because it is billed at cost rather than per seat. A build of this kind runs on Supabase and Vercel. Supabase Pro is USD 25 a month and Vercel Pro is USD 20, both published prices. At RM 4.09 that is about RM 184 a month, roughly RM 2,200 a year, RM 11,000 over five. Adding your thirtieth user changes that figure by nothing, which is the structural difference between the two models.

The third cost is support, and this is the one we have to be honest about because we do not publish a figure for it. Our retainer is scoped rather than listed. For the arithmetic below we assume RM 1,000 a month, and we are labelling that as an assumption rather than a price so you can substitute your own. It is deliberately not a low assumption; understating it would be the easiest way to rig this page.

So two five-year totals. Lean, where you take the system and maintain it yourself: RM 25,000 plus RM 11,000, so about RM 36,000. Supported, with the assumed retainer: about RM 96,000. Real projects sit between those two, and which one you resemble depends less on the software than on whether you have anyone in-house who can read it.

The number of users at which five years of subscription passes the five-year cost of the build. The subscription column carries a RM 6,000 setup, which is inside the RM 2,000 to RM 6,000 range Keyway Digital Labs publishes for a basic accounting-software upgrade in Malaysia. If your off-the-shelf route needs a full consultant-led implementation instead, see the section below, because that changes the answer more than anything else on this page.

Read the spread rather than any single cell. There is no such thing as "the crossover is at N users" — the per-user price you were quoted moves it by more than a factor of three, and how much ongoing support the build needs moves it by another factor of three.

The licence is the visible cost and rarely the deciding one. Keyway Digital Labs, writing in April 2026, puts a basic accounting-software upgrade in Malaysia at RM 2,000 to RM 6,000 and a comprehensive cross-departmental ERP implementation at RM 30,000 to RM 120,000 and above, covering licensing, workflow configuration, LHDN localisation, data migration and staff training. SMURPS makes the same point from the other direction: implementation and migration frequently exceed the subscription itself.

Put that against the build side and the comparison changes character. A RM 45,000 implementation — the low-middle of Keyway's comprehensive band — is more than the entire five-year cost of a lean build, before a single licence has been paid for. That is not an argument that off-the-shelf is bad. It is an argument that the cost you are comparing is not the cost you were shown.

It also explains why the same product produces such different verdicts. Odoo self-implemented by a competent operations manager and Odoo implemented by a partner on a day rate are, financially, two different products carrying the same name. Ask any vendor for the implementation figure in writing, separately from the licence, with the number of man-days behind it and the day rate stated. A quote that will not separate them is telling you something.

Most of the time. If your business buys things, sells things, holds stock, invoices, and pays people, and none of those steps is unusual, then a mature package already models all of it, has modelled it for a decade, and will keep modelling it while regulations change. You should buy it. Nothing we could build in eight weeks competes with forty modules and ten years of edge cases.

Four specific situations where buying is clearly right. One: you are under about ten people and your per-user price is at the low end, because the subscription simply will not accumulate fast enough to matter. Two: you want the breadth and will actually use it — manufacturing, projects, field service, e-commerce and accounting, all connected, is an enormous amount of software to write and a modest amount to rent. Three: you have nobody internally who can hold a specification, and the honest read on a build is that the specification is your job, not ours. Four: you need it running next month.

There is a fifth that gets missed. If your processes are bad and undocumented, a package is a useful discipline — it forces you into a standard shape somebody else has already thought about. Building custom software around a broken process just makes the broken process permanent and expensive. Fix the process, run the package, and revisit the question in two years when you know what you actually do.

The tell is not size. It is whether the thing you bill on has a module. A package models orders, stock, and invoices. It does not model an unbilled haulage trip, a crane-day, a consultancy engagement, a panel claim, or a job sheet with a variance on it. When the operational record your revenue comes from lives in a spreadsheet next to the ERP, you have not implemented an ERP. You have bought an expensive general ledger and kept the real system in Excel.

That is the situation the builds on this site were made for: haulage where invoices are raised from trips that have not yet been billed, crane hire where margin is tracked per machine, manufacturing where reject and weight variances make credit notes routine. In each case the package could have done the accounting perfectly and would still have left the billing driver outside it.

The second tell is per-user pricing colliding with headcount you cannot avoid. If forty people genuinely need to enter or read something, and the subscription taxes each of them, you are being charged for the thing you want more of. The usual response is to restrict licences, which means the data stops being complete, which means the system stops being trusted. That failure is expensive and it never shows up in the comparison.

The third is data ownership. A build deployed into your own GitHub, Supabase and Vercel accounts is an asset with your credentials on it. A subscription is access. Both are legitimate; only one of them survives you changing supplier.

A twelve-person manufacturing or services SME, the size where this question actually gets asked. Subscription at RM 150 per user per month, inside the SMURPS band. Implementation at RM 45,000, the low-middle of Keyway's comprehensive range. Build at our published RM 25,000 floor, plus published infrastructure, plus the RM 1,000 monthly support assumption.

The last row is the one that stops this being a sales table. The routes do not buy the same thing, and pretending they do is how businesses end up with a cheaper system that does less than they needed.

Two businesses running identical operations in different countries can reach different answers here, because Malaysian compliance is not a translation layer on top of an ERP. It is a set of capture rules that have to be true at the point a customer or a line is created.

SST-02 and the e-invoice field model share those rules: registration number, taxable classification, exemption handling. Done as two separate projects they drift, and the figure on the return stops agreeing with the figure submitted to MyInvois. Done once, at capture, they agree by construction. Any evaluation should ask a vendor to demonstrate both from the same record, not to show you two working screens.

The service-tax scope expanded on 1 July 2025, announced by the Ministry of Finance as a targeted revision of the sales tax rate and an expansion of the service tax scope, bringing rental and leasing, construction and financial services among others into the net. If your business was outside it before that date and inside it after, your ERP's tax configuration is now doing work it was never set up for, and that is worth checking regardless of which route you take.

The e-invoicing side has its own dates. The SME band came in on 1 January 2026, with a second date of 1 July 2026 for businesses that commenced operations between 2023 and 2025 and reach RM 1 million or more in turnover. The relaxation runs to 31 December 2027 and full enforcement begins 1 January 2028. A package that submits under today's relaxed rules and a package that will handle per-transaction e-invoices with correct classification codes in 2028 are not necessarily the same package, and the demo you are watching is almost certainly of the first one.

Five inputs, and you can do it in an afternoon. First, the number of people who should be in the system — not the number you can justify licensing, the number who should be in it. That distinction is the whole per-user argument. Second, the per-user price in writing, with the billing period stated, because annual and monthly rates differ by twenty per cent or more.

Third, the implementation quote, separated from the licence, with man-days shown. Fourth, the annual support or maintenance figure on both routes, over five years, not one. Fifth, and this is the one that decides it: list the three things your business is actually billed on, and ask which module handles each. If the answer for any of them is a spreadsheet, the comparison above is not the comparison you are having.

Then multiply. If the subscription total is smaller and the modules cover your billing drivers, buy the package, and we will tell you so if you ask us. We would rather lose a project than sell a build that a RM 6,000 configuration would have beaten.