The question usually arrives as a cost comparison. Someone totals the annual subscription across every seat, sets it beside a quote to build something, and the two numbers land close enough to argue about. That comparison almost never predicts which choice turns out to be right, because the costs that actually decide it appear on neither side of the sum.
The useful version of the question is narrower than the one people ask, and for most of the list it has an unglamorous answer.
Most of Your Subscriptions Are the Right Call
Payroll, email, accounting, calendaring, video calls, e-signature, and the helpdesk queue are commodity workflows. Their core behaviour is broadly shared, and the vendor carries the compliance and security work, and nothing about how your business processes payroll is going to win you a customer. Building any of these means reproducing something that already exists and then owning it indefinitely.
A software partner should tell you this before quoting. If a firm proposes replacing your accounting package with something bespoke, that proposal serves their revenue, not your operations.
Where the Line Actually Falls
The line runs between workflows your customers notice and workflows they never see. Two firms in the same industry can be right to make opposite decisions about the same category of software, because one of them competes on that workflow and the other does not.
A property management firm buys its accounting software and builds its owner portal, because owners compare portals when choosing a manager and nobody chooses a manager for the general ledger. A specialty distributor buys the helpdesk and builds the quoting tool, because the quoting rules encode years of margin decisions that no vendor models. In both cases the bought software runs a process the market treats as identical everywhere, and the built software runs the process the business is judged on.
The test is uncomfortable and quick. If a competitor bought the same subscription tomorrow and configured it the same way, would anything about your service get worse? Where the answer is no, keep buying.
Heavy Configuration Is Custom Software With Worse Tooling
Here is the part that usually gets missed. A team that has firmly decided against custom software often ends up writing a great deal of it anyway, inside the SaaS product, without ever calling it that.
It accumulates as custom fields, validation rules, calculated columns, workflow automations, approval chains, notification triggers, and eventually scripts in whatever language the vendor exposes. Each addition is small and individually reasonable. Nobody reviews any of it as a change to a system. Some months in, the behaviour of a business-critical process lives in a sprawl of settings and a handful of scripts that exist only in production.
Set that beside how the same logic would be handled as code. There is no source control, so no history records who changed the approval threshold or when. There is no branch, so there is no safe place to try a change. There is no test suite, so the only way to learn whether the new rule breaks the old one is to let it run against real records. There is no local environment, so someone edits production configuration while the business is using it. There is no code review, and frequently no way to see a diff at all. When the person who built it leaves, the documentation is the settings screens.
None of that makes the configuration a mistake. The cost was simply paid quietly and recorded nowhere, so a later comparison between SaaS and custom weighs a subscription line item against a full engineering budget while ignoring the engineering work already being done without any of the tooling. Count that work honestly and the comparison shifts.
Can You Actually Get Your Data Out?
The exit surface is the other thing worth checking before a renewal, and you can check it this afternoon. A vendor may advertise an export feature. What matters is whether the export round-trips.
Open the vendor export documentation and look for four specific things: whether internal record identifiers are included, whether the relationships between records survive as usable keys, whether attachments and uploaded files come out attached to the records they belong to, and whether history is included at all, meaning status changes, comments, and the audit trail. A file of current records carrying display names and no join keys is a report. It will not rebuild your data anywhere else.
The same check applies to the configuration from the previous section, which is usually the least portable thing you own. Workflow rules and calculated fields rarely export in any usable form, so the logic has to be rediscovered by reading screens and then reimplemented from nothing. That is the real switching cost, and it never appears on the invoice.
Where IKRC Fits
IKRC builds custom software, so read the following as a position taken against our own short-term interest. For most of the systems on your list the subscription is correct, and we will say so. The work worth doing is usually narrow: the one or two workflows the business competes on, plus the integration layer that keeps the bought systems and the built ones agreeing about the same records. In practice that means software integration and API integration at least as often as new applications, and modernization when something built years ago has become the constraint.
For a concrete starting point, list every subscription, mark the ones a competitor could buy tomorrow with no effect on your service, and look hard at whatever survives the marking. Call IKRC at 646-783-1441 or email info@ikrc.co.
Related Reading
For the data layer underneath either choice, read Before You Add AI, Fix the Data Retrieval Layer. For keeping semantic search inside a database you already run, read SQL Server Can Now Power Semantic Search Without a Separate Vector Database.
Need this solved in your software?
IKRC builds the custom systems, integrations, and modernization work discussed in this article.