No-code and low-code platforms have won the adoption argument. Gartner projects that citizen developers — business users building applications without professional engineering involvement — will outnumber professional developers four-to-one in large enterprises by 2026. The global RPA market alone is valued at $28.31 billion in 2025, projected to reach $247 billion by 2035.
The adoption is real. So is the debt.
The same Gartner research shows that 50% of enterprise applications contain avoidable technical debt, with 30% of CIOs reporting that more than 20% of their new product budget is consumed by resolving technical debt — much of it from ungoverned citizen developer activity. Organizations adopting no-code and low-code at scale without governance frameworks are discovering that the debt is qualitatively different from traditional technical debt, and harder to manage.
This is not an argument against no-code or low-code. It is an argument for having a structured decision framework before choosing one.
Defining the Three Options (Precisely)
The terms are used loosely enough that clarity matters before the comparison.
No-code platforms allow non-developers to build applications or automations using visual interfaces, drag-and-drop logic, and pre-built connectors. No ability to write code. Examples: Zapier, Bubble, Airtable, Microsoft Power Apps (in citizen developer mode). Optimized for: business users, speed, low upfront cost.
Low-code platforms provide visual development environments with the ability to extend with custom code where needed. The target user is a hybrid: a developer who needs speed, or a technical business user who can write simple logic. Examples: OutSystems, Mendix, Appian, Power Apps (in developer mode), Retool. Optimized for: faster application delivery than custom code, with more flexibility than pure no-code.
RPA (Robotic Process Automation) automates specific task sequences — typically mouse clicks, data entry, and form submission — by recording and replaying user actions at the UI layer. Examples: UiPath, Automation Anywhere, Blue Prism. Optimized for: automating repetitive tasks in legacy systems that have no API and where changing the underlying system is not feasible.
Custom software is built by developers using general-purpose languages and frameworks, with full control over architecture, data model, integration, and deployment. Optimized for: complex requirements, deep integrations, regulated workflows, and systems that need to scale predictably.
The Three-Axis Decision Framework
The correct decision is not “low-code vs. custom code.” It is an evaluation across three independent axes. The combination of scores across all three determines the right tool.
Axis 1: Process Stability
How frequently will the process being automated change? A process that is stable — same steps, same data, same systems — for 2+ years is a good automation candidate. A process that changes quarterly because regulatory requirements evolve, product decisions change the workflow, or customer-facing behaviour is being actively iterated is a poor automation candidate.
RPA is the most sensitive to process instability. It automates at the UI layer: screen coordinates, field positions, element identifiers. A software update, a browser version change, or a UI redesign can silently break an RPA bot. Organizations that adopt RPA at scale without a dedicated bot operations function find themselves with dozens of broken automations after each quarterly system upgrade.
Low-code platforms are more resilient to process change than RPA but less flexible than custom code when the change requires logic that the platform’s visual editor cannot express. The breakpoints — where the platform’s abstractions stop working — are not always predictable upfront.
Custom code is the most resilient to process change because the full logic is explicit and modifiable. It is also the most expensive to change, because changes require engineering involvement.
Rule: stable process → RPA or no-code viable. Changing process → low-code or custom.
Axis 2: Integration Complexity
How deeply does the automation need to integrate with other systems, and how clean are those systems’ interfaces?
No-code and RPA platforms excel when integrating with systems that have well-documented, stable connectors. Zapier has 7,000+ app connectors. Power Automate integrates deeply with the Microsoft ecosystem. For these integration patterns, custom code adds cost without adding capability.
The failure mode appears when the integration requirements exceed the platform’s connector library:
- Legacy systems with no API, requiring custom connector development or RPA-style UI automation
- APIs with complex authentication flows, rate limits, or non-standard schemas
- Real-time event streaming (Kafka, Kinesis) rather than polling-based integration
- Database-level integrations that bypass the application API
Low-code platforms can handle moderate integration complexity through custom connectors and code extensions. Custom code is required when integration complexity demands granular control over error handling, retry logic, data transformation, or connection pooling.
Rule: standard connectors + modern APIs → no-code/low-code viable. Legacy systems + complex integration logic → custom code.
Axis 3: Compliance and Data Exposure
What data is being processed, and what regulatory requirements govern its handling?
No-code and low-code platforms are cloud-hosted SaaS products. Your data — including any process inputs and outputs — flows through the vendor’s infrastructure. For most business process automation, this is acceptable. For regulated data categories, it requires explicit analysis:
- PCI-DSS: cardholder data processed through Zapier or Power Automate flows means that vendor is now a PCI scope concern
- HIPAA: PHI flowing through a no-code automation requires a BAA with the platform vendor and an assessment of whether the vendor is a HIPAA-eligible service
- GDPR: data processing in no-code/low-code platforms hosted outside the EU may trigger transfer requirements
RPA is sometimes used in regulated environments precisely because it operates on the local desktop or server, keeping data within the compliance perimeter. This is a legitimate use case — with the caveat that the RPA tool itself, its orchestration platform, and its logs all need to be within scope for the compliance assessment.
Rule: non-regulated data → no-code/low-code vendor risk is manageable. Regulated data categories → explicit compliance assessment required before platform selection.
The No-Code Technical Debt Problem Is Different
When professional engineers create technical debt, it is traceable. There is a commit, an author, a codebase, and a team that can be engaged to address it.
When citizen developers create technical debt through no-code platforms, it is often invisible:
- Business users who built load-bearing processes have left the organization
- No documentation of what the automation does or why
- No one in IT knows the automation exists until it breaks
- The platform’s visual editor is not version-controlled in the same way as a codebase
- Dependencies between automations are not always visible from within the platform
Gartner’s 2025 findings on citizen developer governance are specific: organizations that allow broad citizen developer adoption without an application lifecycle management process — tracking what was built, by whom, what it depends on, and when it was last validated — are consistently discovering automations they did not know existed running processes they cannot reconstruct after the builder leaves.
The governance frameworks that work: a Center of Excellence that reviews citizen developer applications before they enter production, mandatory naming and documentation standards, integration with IT’s change management process, and scheduled lifecycle reviews that identify automations that are no longer needed or no longer functioning correctly.
When RPA Is the Right Answer (and When It Isn’t)
RPA achieves 100-200% ROI in the first 12 months for well-scoped, stable, rule-based processes — a result that is consistently documented across implementations at scale. The conditions for that result:
- The process being automated is genuinely stable (no UI changes expected)
- The task is genuinely repetitive (the same sequence, with the same inputs, every time)
- The underlying systems cannot easily be integrated via API (legacy mainframe, vendor-locked application)
- Volume is high enough to justify the implementation and maintenance cost
RPA is the wrong tool when:
- The process changes frequently (maintenance cost will exceed savings)
- An API integration is available (RPA is the fragile option; APIs are the robust option)
- The process involves significant decision logic (rules engines or ML models are more appropriate)
- Scale beyond desktop-level automation is required (enterprise RPA orchestration adds significant complexity)
The most common RPA mistake: automating a process that could have been integrated at the API layer. RPA on top of an application that has a well-documented API is borrowing against your future maintenance budget to avoid an integration project today.
How we approach this at Insoftex
The build-vs-configure decision is the most frequent initial question in our engagements, and we have a strong prior against recommending custom development when a platform solution would genuinely work.
The reason we see custom development consistently fail to deliver on no-code/low-code promises is not that the platforms are poor. It is that the selection decision was made on cost grounds alone, without evaluating process stability, integration complexity, and compliance exposure. A client who discovers their no-code automation cannot handle a regulatory data requirement six months into a deployment has not saved money — they have spent it twice.
The analysis we run before any recommendation: three axis evaluation (stability, integration, compliance), then a total cost of ownership model that accounts for platform licensing, maintenance overhead, and the cost of expected process changes over a three-year horizon. Custom development usually wins on the three-year TCO when integration complexity is high or process change is frequent; no-code/low-code wins when both axes are low and compliance exposure is manageable.
For regulated industries specifically — financial services, healthcare, government — we treat compliance axis evaluation as non-negotiable before platform selection. A platform that processes regulated data without explicit compliance verification is not a risk we allow clients to accept inadvertently.
Deciding between no-code, low-code, RPA, and custom development for a specific workflow? A 30-minute technical call with one of our senior engineers will tell you which option is right for your situation — and why. No pitch, just analysis.