The usual version of this argument compares a monthly subscription to a project quote, concludes that the subscription is cheaper, and stops. That comparison is wrong in both directions and it ignores the cost that actually decides the outcome.
Count what the platform costs you in workarounds
A platform that fits eighty percent of your process is not eighty percent of a solution. The remaining twenty percent becomes a spreadsheet, a shared inbox, or a person whose job is copying fields between two systems.
That cost is real and it is invisible, because it never appears on an invoice. Before comparing anything, count it. How many hours a week go into the workaround. How many errors it produces. What it costs when the person who maintains it is away.
Use your own operating records to estimate that cost. Do not accept a supplier’s claim that a custom build will pay for itself without examining the assumptions and the continuing maintenance work.
Count what a build costs over its life
The quote is not the cost. A custom system has ongoing maintenance: dependency updates, platform changes, integration drift as third parties revise their APIs, and the changes your own business will want.
Budget for it explicitly rather than being surprised. A reasonable planning assumption is that a system needs meaningful attention every year, and that attention has a cost whether it comes from a supplier, a support plan or your own team.
Also count the risk. A build can be late or wrong. A platform is available on Tuesday. That certainty has value and should be part of the comparison rather than dismissed.
The question that actually decides it
Is this process a thing you compete on, or a thing you have to do?
Payroll is a thing you have to do. Nobody wins work because their payroll is distinctive. Buy it.
The way you schedule crews, price jobs, qualify leads or manage a service lane may well be a thing you compete on. If your process is genuinely better than the sector default, a platform that normalises you to the sector default is removing your advantage and charging you monthly for the privilege.
The honest test: if a competitor adopted the same platform and configured it the same way, would you still be better? If yes, the process is not where your advantage lives and you should buy. If no, that process is worth owning.
The signals that a build is due
Several of these together usually settle it.
Platform fees have become a material line item, particularly percentage based fees that scale with revenue while the platform does no more work.
You are paying for several tools whose overlap is significant, plus the integration work to keep them agreeing with each other.
A workaround has become load bearing. There is a spreadsheet the business cannot run without, maintained by one person.
The platform cannot express a rule your business depends on, and the vendor roadmap does not include it.
You have hit a ceiling on data access. You cannot get your own information out in a usable form, or reporting requires an export and a pivot table every week.
The signals that buying is correct
Equally worth naming honestly.
The process is standard and your version of it is not better. Accounting, payroll, email and calendaring are the obvious cases.
Regulatory complexity is high and a vendor absorbs it. Building something that has to track changing rules is a permanent commitment.
You need it in three weeks.
Volume is low. A process that runs twenty times a month rarely justifies a build no matter how badly it fits.
The answer is usually hybrid
The most common correct outcome is not one or the other. It is: buy the commodity systems, build the part that is specific to you, and integrate them properly so there is one place that decides what is true.
That keeps the accounting system, the payroll system and the email platform, and replaces the spreadsheet that sits between them with software that enforces your actual rules. It is cheaper than replacing everything and considerably better than living with the workaround.
The integration is the part people underestimate, and it is the part worth engineering carefully: ownership of each field decided explicitly, reconciliation that reports drift, and failures that are visible rather than silent.
Run the awkward transaction before choosing
Choose a real workflow that the current system handles badly. For a wholesale order, that might be a partially fulfilled line, a changed delivery date and a customer specific approval rule. Ask a prospective platform to demonstrate the whole sequence with representative data. A slide showing order management is not evidence that it can express those particular rules.
Write down where each option requires configuration, custom code, manual work or a change to the business process. That produces a more useful comparison than a checklist of feature names. A platform may support an approval field but lack the rule preventing dispatch before approval. A custom build may support the rule but still depend on a carrier integration that needs separate work.
Include an exit exercise in the trial. Export the order, its history, attachments and references. Check whether another system could reconstruct the workflow from that export. If not, record the future migration work as part of the decision.
For the custom option, request a small technical investigation of the uncertain dependency rather than assuming it is straightforward. The question is not whether an engineer can draw the desired screen. It is whether the chosen systems can exchange the information the screen depends on, under the access and operational constraints the business actually has.