Custom Software vs SaaS: When Malaysian SMEs Should Build
SaaS fits most problems — until your business stops fitting the tool. Five signals Malaysian SMEs have outgrown off-the-shelf software, and how to decide what to build.
Most Malaysian SMEs should not build custom software. Accounting, payroll, email and e-invoicing are solved problems, and the products that solve them improve every month without you paying a developer.
The mistake is in the other direction: companies that keep bending their operation around tools that no longer fit, and hire people to fill the gaps between them. That is a software problem disguised as a headcount problem.
The SaaS ceiling
Off-the-shelf software is built for the average customer in its category. The closer your process is to that average, the better it fits. The ceiling arrives when the thing that makes you competitive — how you quote, how you schedule, how you onboard a client — is exactly the part the tool handles badly.
You usually notice it indirectly:
- Data is typed twice. An order arrives on WhatsApp, goes into a spreadsheet, then into the accounting system. Every copy is a chance for an error, and every error costs a phone call.
- A spreadsheet runs the core. One workbook, owned by one person, holds a process the business cannot stop. When that person is on leave, the process waits.
- Growth means admin hires. Revenue rises, but so does the number of people needed to process it. Margin does not follow growth.
- Seats cost more than they fit. You pay per user for three tools that each cover 60% of the job — and still need workarounds.
- Customers wait on manual steps. Quotes, reports or onboarding take days because someone assembles them by hand.
One of these is normal. Three or more is a signal to look properly.
Buy, integrate or build
In our audits, the answer is more often integrate than build. Many SMEs already own decent tools; the waste is in the people moving data between them. Connecting a CRM, an accounting package and WhatsApp Business through APIs or an automation platform removes the retyping without replacing anything.
We use a simple rule set:
| Option | Choose it when | Watch out for |
|---|---|---|
| Buy | The process is standard and the tool fits most of how you work | Per-seat costs growing faster than revenue |
| Integrate | Good tools exist, but people move data between them | Fragile links without monitoring and alerts |
| Build | The process is how you compete, nothing fits, and the leak pays back the build | Software with no internal owner |
The third column matters as much as the second. Integrations fail quietly if nobody monitors them. Custom software decays if nobody on your side understands it. Both risks are solved the same way: documentation, handover training and an owner in your team. That is why we treat training and building as one practice.
Put a number on the leak first
The decision to build should be a comparison of two numbers: what the manual process costs per year, and what the system costs to build and run. Most companies only know the second.
Estimating the first is not complicated. Count the people who touch the process, the hours per week each spends on it, and a loaded hourly cost. Add the cost of errors — refunds, re-work, lost deals — if you can see them. This is the core of the Leak Ledger in our AI Opportunity Audit, and you can do a rough version yourself with our free Opportunity Scorecard.
If the annual leak is small, buy or integrate. If it is large and growing with the business, a build usually pays for itself — and keeps paying as volume rises, because software does not need to be hired again.
What a sensible first build looks like
The best first builds are narrow. Not "an ERP replacement", but one process end to end: enquiry to quotation, order to invoice, lead to follow-up. A narrow build ships in weeks rather than months, proves the numbers on real data, and gives your team a system they understand before anything larger is attempted.
Three things should be agreed in writing before any code is written:
- The KPI. Hours saved per week, time from enquiry to quote, error rate — measured before kickoff so the result is not a matter of opinion.
- Ownership. Who in your company owns the system after go-live, and who holds the source code and data (it should be you).
- Data boundaries. Which data the system touches, where it is stored, and — if AI is involved — which models see it. This is where PDPA obligations are met or missed.
The bottom line
Buy when the problem is standard. Integrate when your tools are fine but disconnected. Build when the process is how you compete and the leak is large enough to measure. And whichever you choose, train the people who will run it — software only pays when it is used.
If you are unsure which side of the line you are on, a 30-minute call is usually enough to tell.