Custom software versus a platform: how to decide for an ops team
Ops teams weighing a custom build against a low-code platform keep comparing feature grids. The real question is how often the workflow changes and who ends up owning the integrations.
The ticket came in on a Tuesday. A dispatcher wanted one extra field on the shift handoff form. Simple request. Nobody on the ops team could make the change.
The form had been built eighteen months earlier in a low-code platform. The consultant who built it had left. The vendor's upgrade had broken two of the automations. The person who knew why the approval step routed to a dead mailbox was on leave. So the field waited three weeks, and during those three weeks the team kept a shadow spreadsheet next to the official tool.
That is the failure mode nobody puts in the demo. The platform did what it promised. The problem was that the workflow kept moving and the tool did not move with it, and nobody owned the seams.
Start with how often the workflow changes
Most comparison pages start with features. Forms, permissions, audit logs, mobile support. Those matter, but they don't decide anything. Two products can tick the same boxes and still produce opposite outcomes.
The question that does the work is simpler: how often does this process change? If your handoff rules shift every quarter because the business is reorganizing, a platform's configuration model will get stretched until it cracks. If the process has been stable for years, buying is almost always cheaper, and you should feel no shame about it.
Count the changes. Pull the last twelve months of requests that modified the workflow, not the data. If the number is in the dozens, you are maintaining a product, whether you admit it or not. Plan for that.
Integrations decide who gets paged
Every ops tool is really a set of integration points: the ERP feed, the ticketing system, the email gateway, the badge reader that someone wired up in 2019. The integrations are where things break.
With a platform, connectors are usually managed by the vendor, which sounds like relief until a connector update changes a field mapping and you find out from a downstream report. You can file a ticket. You cannot fix it.
With custom software, you own the glue code. That is more work and more responsibility, but the fix is in your repository and your on-call rotation can reach it. Ask a blunt question before you choose: when the feed from the warehouse stops at 2 a.m., who can open the code that handles it, and how long does that take?
If the answer is "the vendor's support queue," you have bought a dependency. Sometimes that is acceptable. Price it in.
What the platform actually costs over three years
License price is the number on the quote and the least informative number in the file. The costs that surprise teams are the ones around it: the consultant who has to be retained for every change, the workaround layer of scripts and spreadsheets that accumulates beside the official tool, the migration cost when you eventually leave, and the internal time spent explaining the platform's quirks to each new hire.
I would not put specific figures here without checking them against your own vendor quotes and a few reference customers. Build a three-year model with those line items, and treat any published industry benchmark as something to verify, not something to quote.
Lock-in is the hardest to price. Ask how you would export the workflow logic, not only the data. Many platforms export records cleanly and leave the rules behind.
A decision test you can run this week
You do not need a steering committee. You need four numbers and one conversation.
Count workflow changes in the last year. Count the integration points. Ask who can deploy a fix without a vendor and how long that takes in practice. Estimate the cost of leaving in three years.
If change is high and you own the integrations anyway, build, and keep the scope small. If change is low and the integrations are standard, buy and stop agonizing. The messy middle, where the platform is fine today and the workflow is drifting, is where most teams end up, and it is the case where the test pays for itself.
The platform is not the risk. An unowned workflow is. Decide who owns the change and who owns the seams, and the rest of the comparison gets much shorter.
