Low-Code Isn’t Dead. But I’d Put Less in It.

Development speed is no longer enough

A colleague gave OutSystems Mentor a serious try for a loan-origination application. He prepared a five-page specification and wanted to make the platform work. Across repeated attempts, generation failed to finish. The immediate problem wasn’t whether the resulting application was ready for production. He couldn’t reliably get a completed starting point to evaluate.

His team also used Claude Code and tried to make a like-for-like comparison. For the applications they were evaluating, he ultimately couldn’t justify the platform. They now use Claude Code for a range of development work. This wasn’t a controlled benchmark, and a failed generation doesn’t prove that one tool is universally better. What matters is that AI-assisted conventional development gave a customer who wanted to stay with the platform a credible alternative.

That changes what I expect from a rapid-development demonstration. Generated screens, tables, and basic application logic are no longer sufficient evidence of a meaningful advantage. I want to understand how much work remains, how difficult the result is to change, and how the team will test it. Waiting for generation, correcting the output, and working around its assumptions all count as development time.

For a straightforward application, I would now consider an implementation the team can build and own with AI assistance before making a long-term platform commitment. Language and framework choices still matter, as do security and maintainability. The platform has to demonstrate what it contributes beyond the initial build, and the people doing the work need time to examine the output of either approach.

The cost of building everything in one place

One frustration I’ve had with OutSystems is the effort involved when a design doesn’t fit the supplied components. Extending a component is different from choosing the underlying framework and implementing the behavior directly. In projects I’ve worked on, a small interface change could turn into hours spent understanding and working around the platform’s structure. That effort belongs beside the subscription price when evaluating cost.

Standard components save work when they fit. The larger problem starts when an established platform becomes the automatic destination for every requirement. Interfaces, data access, integrations, background processing, AI, and specialist workloads accumulate inside it because that is where the team has been told to build. Each decision may look convenient in isolation. Together, they create dependencies that become difficult to separate.

The subscription should not determine where every responsibility lives. A custom frontend can call a platform-backed service, and specialist processing can run elsewhere. Digibee can expose a pipeline through a REST endpoint, while OutSystems supports exposing services to external consumers. Both can participate in an architecture with an independently developed interface. Digibee REST triggers, OutSystems data sharing

That separation gives the team room to change the user experience without rebuilding the integration layer. An API also provides a defined place to replace an implementation, but the replacement still has to be built. With Digibee, I would budget for rebuilding platform-specific pipelines if we moved away unless an independently runnable exit path had been demonstrated. Exporting configuration or execution information does not establish that an integration can operate elsewhere.

AI can make these changes more approachable at the edges first: building a separate frontend, replacing a component, wrapping an integration, or prototyping an alternate backend. It can help developers understand unfamiliar code and generate tests for behavior they need to preserve. That makes incremental change more practical without making a deeply integrated enterprise platform disposable overnight.

Where an integration platform can still earn its place

Consider a backend that receives orders, queues work, calls several downstream systems, and has to recover when one becomes unavailable. Generating the initial implementation leaves important questions unanswered. What happens when a message arrives twice, a worker stops midway through processing, or a retry repeats an operation that already succeeded? Partial failures need deliberate handling, along with idempotency so that repeating a request does not unintentionally repeat its business effect.

RabbitMQ, Amazon SQS, and similar services require decisions about delivery behavior, retry limits, dead-letter handling, credentials, capacity, and recovery. Those decisions deserve another look as the workload changes. A generated configuration is a starting point. The people operating it still have to understand how the system behaves under load and when its dependencies fail.

For this kind of integration-heavy workload, I would be inclined to evaluate Digibee. Its documentation includes reprocessing patterns and metrics for queueing, pipeline execution, errors, and connector latency. A representative workload with deliberate failures would tell me much more about its value than a demonstration of connecting two systems. Reprocessing guidance, pipeline metrics

Reliability, recovery, governance, and operational simplicity are credible reasons to pay for a platform. The benefit is reducing the burden on the people responsible for the integration and giving them a system they can understand and maintain. Their expertise remains essential. They shouldn’t have to assemble every supporting capability themselves, nor should a visual workflow become an excuse to remove them.

Observability is central to that evaluation, and it has been one of my frustrations in the OutSystems work I’ve encountered. Technical logs and business-transaction visibility are different things. A timeout tells me a request failed to return; it may not tell me whether the supplier accepted the order. Before retrying, I need to establish which steps completed, which downstream calls succeeded or failed, whether retries already happened, and what state the transaction is actually in. If the platform hides that context, the people maintaining it pay for the convenience elsewhere.

Leaving needs to be more than a contractual possibility

OutSystems has a documented detachment process for O11. It describes a complete departure from the platform, rather than detaching selected applications while leaving others on it. The process requires .NET lifecycle expertise and infrastructure preparation, involves losing platform development and operational capabilities, and leaves changes to detached source unsupported by OutSystems. O11 detachment documentation

I’ve worked with clients who tried to maintain detached applications. In those situations, I saw the result as a way to keep something running while planning its replacement, rather than a development foundation I would willingly choose for the following several years. Having the source code tells you little about how comfortably a team can understand, modify, test, and support the result.

That O11 documentation should not be carried into an ODC buying decision as though the arrangements were interchangeable. Be clear about the product, the deliverables, and the contractual terms. For any proposed exit, I would ask to see it work: obtain the application and data, run them independently, make a meaningful change, and deploy it. Include the people who will have to maintain it.

Conventional development creates dependencies too. Frameworks, libraries, cloud services, and operational practices can make a system difficult to move. Owning a repository is not enough. I care about whether the team can identify those dependencies, replace them in manageable pieces, and retain control over how the application evolves. AI can assist with the migration work; the engineering judgment and responsibility remain with the team.

AI features need their own cost justification

I apply the same scrutiny to Agent Workbench. An independently hosted agent can be exposed through an API and consumed by an application. Invoking it through a platform does not establish additional value on its own. OutSystems advertises orchestration, human review, governance, and observability around execution. What matters to me is how well those capabilities serve the actual process and how much work is left for the team. Agent Workbench

Execution capacity and model usage need to be understood separately. OutSystems currently advertises an included monthly agent-execution allowance for ODC, while its FAQ says customers pay external AI providers directly for model-token consumption. Check additional capacity and applicable commercial terms against the agreement. Inference and orchestration are distinct services, but I want a clear explanation of what the second payment buys, particularly when the organization already pays for the underlying platform. Agent orchestration, pricing FAQ

For a document-processing workflow, I would compare the cost of getting a document through to an accepted result, including unsuccessful attempts, retries, validation, and human review. I also want to see which model and configuration were used, what evidence was provided, which tools were called, and why a request was held. Access to that information needs appropriate controls, without indiscriminately recording secrets or personal information.

An independently developed service faces the same requirements. AI-generated code still needs authorization checks, integration testing, security review, useful diagnostics, and ongoing maintenance. Faster implementation can increase the amount of behavior needing examination. That gives us more reason to invest in QA and the people who understand the application.

What I would choose now

For new websites, interfaces, and straightforward applications, I would consider AI-assisted conventional development before making another long-term platform commitment. For complex integrations, iPaaS remains an option where it demonstrably makes the system easier for the team to operate. I would keep its responsibilities defined instead of pulling unrelated work into it because the subscription already exists.

For existing systems, I’d start with upcoming changes, recurring friction, and components that could be separated without creating more risk than they remove. A wholesale rewrite needs its own justification. The comparison must include hosting, upgrades, dependencies, and maintenance alongside platform licensing, customization, execution capacity, and eventual migration.

I don’t think low-code or iPaaS is dead. I’m less convinced that either should sit at the center of everything. I’m willing to pay for a platform that makes a difficult part of the system easier for people to operate. It’s harder to justify paying indefinitely for development speed I can achieve elsewhere, especially when my team then has to work around the platform’s constraints. The point of using AI here is to give those people better options and more time to do the work well, not to turn the time saved into a reason to eliminate their jobs.