Build vs buy: when custom beats SaaS for a Malaysian SME

A founder calls. They want a custom CRM. Or a custom inventory system. Or a custom AI agent. The first thing we tell them is to consider not building it.

Not a sales tactic. SaaS is the right answer most of the time, cheaper, faster, vendor handles the boring parts (uptime, security patches, browser compat, mobile). For any software-shaped problem, default to: find SaaS that fits. Look at three options before you give up.

The harder part is recognising when the default is wrong.

The three signals that custom beats SaaS

Signal 1: A year inside the SaaS, same wall every month

Most reliable signal. Not "feels limited after a demo", every SaaS feels limited after a demo. The real signal: twelve months of actual use, and your team is still doing the same workaround every month. And the workaround is what makes the tool usable at all.

Example: a distribution business on a popular regional ERP. Every month, export orders to Excel, pivot to compute supplier credits, paste the result back into the ERP as journal entries. Three days of work, every month, for a calculation the ERP could not do natively because credit terms varied by supplier and product line.

That is a custom-build signal. Workflow not exotic. Volume justifies the work. The workaround is a tax that compounds. After a year, replacing it with code pays for itself many times over.

Signal 2: The thing you are buying is also your differentiator

If you sell custom-blended industrial chemicals based on a customer's water profile, the formulation engine is your business. A SaaS formulation tool, if one even exists, will be built for someone else's specifics. Over time your competitors use the same tool. Edge gone.

Same goes for a logistics company whose routing engine is what makes their delivery prices viable. Or an investment advisor whose portfolio construction logic is what clients pay for. Anything that is your business should not be rented from a vendor who can sell the same thing to your competitors next quarter.

The reverse is also true: anything that is not your differentiator, accounting, payroll, calendar, video calls, should almost always be SaaS. Owning the code for these gets you nothing and costs you forever.

Signal 3: The integration you need does not exist and never will

Sometimes the right SaaS exists, but your business runs on five tools that do not talk to each other, and the missing integration is a recurring source of error. You asked the vendor. Checked Zapier, Make, n8n, Workato. The integration either does not exist, or exists in a form too generic to handle your edge cases.

Custom middleware in this case is genuinely faster, cheaper, and more reliable than rewriting your entire stack to fit a vendor whose roadmap might never get to your integration. We have built dozens of these. Each one small, scoped, replaces a real source of pain.

This signal is different from Signal 1 because the SaaS tools themselves are fine, what is missing is the connective tissue between them.

Three signals you should not build custom

Signal 4: You cannot describe what done looks like in two sentences

If you cannot say "this system is done when X, Y, and Z are true," do not start a custom build. Custom software is a commitment to a specific design. Without a clear definition of done, the project becomes a moving target, and the cost compounds with every change.

The fix is not to commit to a vague custom build. Use SaaS as a forcing function: pick the closest off-the-shelf tool, use it for three months, let the experience clarify what you need. By month four you can write the two sentences honestly. Then decide.

Signal 5: The reason for custom is "we want our own thing"

Status is not a reason. Neither is "the off-the-shelf one looks ugly" or "we want full control." These feel like product reasons but they are preference reasons. Preference reasons do not survive year two, when the original founder has moved on and the system needs someone else to maintain it.

If the cleanest reason for going custom is preference, use SaaS instead. Put the budget into design polish on the parts that face customers.

Signal 6: The vendor exists, ships often, and your gap is small

Sometimes the right SaaS exists but is missing one feature you need. Before going custom, ask: does the vendor ship updates regularly? Is the feature on their public roadmap? Would they add it if you (or your industry) asked? Serious B2B SaaS vendors do respond to specific, well-framed feature requests, especially from customers who can articulate the use case clearly.

Faster to wait three months for a vendor update than to build, ship, and maintain custom software forever.

The 30-minute test

Here is a test that surfaces the right answer in most cases. Sit down with the person who would use the system every day. Answer four questions.

1. Map the current process end-to-end, including the Excel and WhatsApp parts. Write it as a numbered list of steps.
2. Where does time get lost or errors get made? Mark those steps with a star.
3. For each starred step, what would a tool need to do to remove the problem? Be specific, "auto-calculate supplier credit by product line and credit term" beats "automate finance."
4. Does any SaaS you have evaluated do exactly that? If yes, answer is SaaS, you are over-thinking it. If no, and you can articulate why not, you are looking at a real custom case.

In our experience, this test resolves three out of four "should we build custom?" conversations in 30 minutes. The one remaining is usually a real custom case worth taking seriously.

When you do start custom, start small

If the test does point to custom, the next mistake is over-scoping the first build. We have seen six-month, six-figure first-phase plans go nowhere, because there is no way to know if the design is right until the team is using it.

Start with the single workflow that has the strongest custom-build signal. Ship it in four to eight weeks. Use it for three months. Then decide whether to expand. The discipline of small first phases is what separates custom builds that change the business from custom builds that quietly become legacy.

Same advice every time. The default is SaaS. The exception is real, but rare. When the exception applies, ship something small that proves the model before committing to anything bigger.