Custom vs Off-the-Shelf Software for an SMB: An Honest Decision Guide

The thesis: buy the commodity, build the difference

Off-the-shelf SaaS wins whenever your process is a commodity: email, accounting, payroll, ticketing. The vendor amortises R&D across thousands of customers, so you get depth you could never fund alone. Don't rebuild what you can rent.

Custom pays off in the opposite case: a workflow that is your edge, where the packaged tool forces you to work the vendor's way instead of yours. If you're paying people to bridge gaps with spreadsheets and copy-paste, that gap is the build.

So make the buy-vs-build call one workflow at a time: classify each as commodity or differentiator, then buy the first set and build the second.

When packaged SaaS is the right call

Reach for a product first. It's cheaper on day one, maintained by someone else, and available right away. For the majority of back-office functions, that's the correct trade.

SaaS is right when the fit is good enough and the cost of being slightly off-process is low.

• The process is standard and not a competitive advantage, so buy it.
• A mature category already exists with real depth (security, compliance, integrations).
• Your volume is low enough that per-seat pricing stays cheaper than engineering time.
• You can live inside the vendor's model without a layer of manual workarounds.

When custom actually pays off

Custom earns its cost when the software is the operating model itself. We've seen this repeatedly: a sales-pipeline CRM for Ceiling Impex that replaced a six-person shared-Excel lead register, with six configurable stages, weighted forecasts, dual SSO, a contact graph and full audit history. The Excel register was failing because six people were editing one file with no scope rules and no history.

Other builds are custom because the rules are yours and legally load-bearing. A Section 138 cheque-bounce case manager auto-computed statutory deadlines under the Negotiable Instruments Act 1881 with audit logs. No packaged tool encodes that. A multi-office law-firm ERP carried matter management, billable hours, GST-ready invoicing and SharePoint document control.

The signal is consistent: build when the workflow is your differentiator, when off-the-shelf forces manual workarounds at scale, or when domain rules don't exist in any product.

The hybrid middle path: Power Platform

Most SMBs sit between the extremes, and that's where the Microsoft Power Platform earns its place. If your team already runs on Microsoft 365, you can build on Dataverse, automate with Power Automate, surface a Copilot Studio bot grounded on your own data, and reuse your existing SSO, without standing up a full custom stack.

This is how the law-firm ERP ran a four-step invoice approval chain on Power Automate, and how the cheque-bounce build wired its workflow automation. The hybrid is right when you need real process logic and integration but not a bespoke application: keep the commodity in SaaS, model the differentiating workflow on the platform your team already uses.

De-risking a custom build

The honest risk with custom is building against assumptions nobody checked. You de-risk it by understanding the work before anyone builds: sit with the people who do it today, document every step, exception, and approval, and agree the scope in writing before development starts.

Then hold the build to that document. Review each milestone against the agreed scope, so screens, workflows, roles, and reports are checked against what was signed off rather than against memory. When something needs to change, treat it as an explicit change to the scope, with its effect on effort and timeline agreed before the work begins.

Two more guardrails. First, scope the first build to the single workflow that hurts most: prove value on the differentiator before expanding. Second, plan the data migration as part of the scope: list what moves from the old spreadsheets and registers, who cleans it, and who signs it off. And treat the audit trail as a first-class requirement from day one. For anything legally or financially load-bearing, that log should be append-only by design.