Custom vs Off-the-Shelf Software for an SMB: An Honest Decision Guide
Most SMBs don't need to choose between buying and building. The real question is which parts of your workflow are worth owning — and which you should rent.
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 the decision isn't buy-vs-build as a whole. It's a sort: classify each workflow 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 live this week. 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 — 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, not a side tool. We've seen this repeatedly: a sales-pipeline CRM that replaced a six-person shared-Excel lead register, with six configurable stages, weighted forecasts, dual SSO, a contact graph and full audit history — shipped in five weeks. The Excel register wasn't failing for lack of features; it was failing because six people editing one file has 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 you already own.
De-risking a custom build
The honest risk with custom isn't the code — it's commissioning a months-long build against assumptions that turn out wrong. You de-risk by shrinking the feedback loop, not by writing a longer spec.
Insist on working software early and a standing demo cadence: see the real thing in week two, review it every Friday. That turns a six-month bet into a series of one-week bets, each one cheap to correct. Most of our builds land in four to six weeks precisely because scope is sliced thin and validated continuously.
Two more guardrails. First, scope the first build to the single workflow that hurts most — prove value on the differentiator before expanding. Second, demand portability by design: a cross-database schema and standard SSO mean you're not locked to one vendor's runtime. 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.
Don't decide buy-vs-build for your whole company. Sort each workflow: rent the commodities as SaaS, build the differentiators, and use the Power Platform hybrid for the middle ground — then de-risk any build with working software by week two and a weekly demo.
Frequently asked
Is custom software always more expensive than SaaS?
Not over the full lifecycle. SaaS is cheaper on day one and for commodity functions stays cheaper. But when a packaged tool forces a team to bridge gaps with spreadsheets and manual copy-paste, the recurring labour cost can exceed a one-time build. Compare total cost of ownership, including the people-time spent working around the tool, not just licence fees.
What is the Power Platform hybrid, and when should an SMB use it?
It's the middle path between buying and building: model your differentiating workflow on Microsoft's Power Platform — Dataverse, Power Automate, Copilot Studio — reusing your existing Microsoft 365 SSO. Use it when you need real process logic and integration but not a full bespoke application, and you keep commodity functions in off-the-shelf SaaS.
How do you de-risk a custom build before committing months of budget?
Shrink the feedback loop. Require working software in roughly week two and a weekly demo, so a long bet becomes a series of one-week bets that are cheap to correct. Scope the first slice to the single most painful workflow, and design for portability — standard SSO and a cross-database schema — so you avoid lock-in.