I build custom software for a living, so what I am about to say cuts against my own commercial interest: most businesses that ask me for custom software should not buy it. The SaaS vs custom software decision is one that owners consistently get backwards, building what they should rent and renting what they should own.
The pattern I see, over and over: a company spends Rp 200 million building a custom HR and payroll system (a solved problem, available as SaaS for a fraction of that), while running the one process that actually makes them different from competitors on a tangle of spreadsheets and WhatsApp groups.
The framework for getting this right fits in one sentence. Buy for the 80 percent of your operations that look like everyone else's. Build only for the 20 percent that is your competitive advantage. The rest of this article is how to apply that sentence honestly, including the three-year math.
The 80/20 Rule of Business Software
Every business is a bundle of processes. Be honest about which bucket each one falls into:
Commodity processes. Accounting, payroll, HR administration, email, file storage, basic CRM, help desk, video meetings. Your accounting is not special. Neither is mine. Debits and credits work identically at your company and your competitor's, and Indonesian tax rules apply to everyone equally. Thousands of companies have the same need, which is exactly why good SaaS exists for it: Accurate or Jurnal for accounting, Talenta or Gadjian for payroll and HR, Google Workspace for email and files, Mekari Qontak or a dozen others for CRM.
Differentiating processes. The one or two workflows where you genuinely beat competitors. For a distributor it might be a routing and consignment model nobody else runs. For a lender, a credit scoring approach. For a manufacturer, a production scheduling method that gets 15 percent more out of the same machines. This is the process customers indirectly pay you for.
The rule follows directly:
- Commodity process → buy SaaS. You get years of accumulated features, security patches, and compliance updates for a monthly fee. Building this yourself means paying to reinvent something worse.
- Differentiating process → consider building. Forcing your unique advantage into a generic tool sands off exactly the edges that make you win. And there is a second reason to build here that owners underweight: custom software encoding your differentiator is an asset you own, while a SaaS subscription is rent forever.
Everything in between, and there is plenty in between, defaults to buy, configured as close as you can get.
The Three-Year Total Cost Math
Sticker prices lie in both directions, so run the comparison over three years. Here is a realistic example for a mid-sized Indonesian SME evaluating an operations tool for a 25-person team.
SaaS option:
| Item | 3-year cost |
|---|---|
| Subscription, 25 users at ~Rp 150k/user/month | Rp 135 million |
| Onboarding and configuration | Rp 10 million |
| Integration glue (exports, connectors) | Rp 15 million |
| Total | ~Rp 160 million |
Custom build option:
| Item | 3-year cost |
|---|---|
| Initial development | Rp 250 million |
| Maintenance and hosting, ~15-20%/year | Rp 120 million |
| Enhancements (you will want them) | Rp 60 million |
| Total | ~Rp 430 million |
Two honest observations. First, custom is rarely cheaper inside three years, and anyone who quotes you a build price without the maintenance line is hiding half the invoice. I broke down where those build costs actually come from in What Custom Software Really Costs. Second, the SaaS line scales with headcount and never ends, while the custom curve flattens after the build. Around year four or five, for a stable process and a growing team, the lines can cross. That is why the deciding factor is not price. It is whether the process deserves to be owned at all.
Where Each Option Quietly Fails
The spreadsheet comparison misses the failure modes, which is where real money goes.
How SaaS fails you: the vendor raises prices once you are locked in; the feature you need sits on a roadmap you do not control; your data lives in their format and exporting it cleanly is painful; the product gets acquired and stagnates; and per-user pricing that felt cheap at 10 people stings at 80. Mitigation: before signing, test the export function, not the demo. Your exit path matters more than the entry price.
How custom fails you: the initial estimate doubles; the vendor delivers and disappears, leaving you with code nobody else wants to touch; shortcuts accumulate until every change is slow and risky, a dynamic I explained in Technical Debt Explained: Why Your App Gets Slower to Fix; and you discover you have paid a premium to own a worse version of something that existed off the shelf. Mitigation: never build until you have seriously tried to buy, and never sign a build contract without a maintenance agreement and code ownership in writing.
The Decision Checklist
For any given process, answer these five questions in order:
- Is this process how we win customers, or just how we operate? Just operating → buy. Stop here.
- Have we actually trialed the two or three leading SaaS options? Not brochures, real trials with real data for two weeks. If a SaaS covers 80 percent of the need, buy it and adapt the remaining 20 percent of your habits. Changing a habit is cheaper than maintaining software for a decade.
- Is the process stable and proven? If you are still figuring out how the workflow should even run, do not freeze it in custom code. Run it manually or on cheap tools until it stops changing.
- Can we fund the whole lifecycle, not just the build? Rule of thumb: total cost of ownership is two to three times the build quote over five years. If that number hurts, the answer is buy.
- Do we have someone to own the vendor relationship and the asset? Custom software without an internal owner becomes orphan software within two years.
Only a process that survives all five questions earns a custom build. In my experience that is one process per company, sometimes two, almost never five.
There is also a hybrid that deserves more use than it gets: buy the commodity core, build a thin custom layer on top. SaaS accounting plus a small custom app that handles your unusual consignment logic and pushes clean journal entries into it. You own only your differentiator, and rent everything else. Total cost often lands well under either pure option.
The Practical Takeaway
The SaaS vs custom software question is not a technology decision, it is a capital allocation decision. Rent the processes that make you normal. Own the process that makes you different, once it is stable, once you have honestly tried to buy it, and once you can afford its full lifecycle.
Map your top ten processes into commodity versus differentiating this week. If your custom-software budget is pointed at the commodity column, redirect it before you sign anything. And if you have exactly one process in the differentiating column and you are weighing whether it deserves a build, that is a conversation worth having with someone who has sat on both sides of the table. You can find me through the partnership page.