When to bring OutSystems to a Next.js shop

We run a product engineering practice that ships a lot of TypeScript. Next.js, React Native, Python services, Postgres, the usual modern stack. We also run an OutSystems practice. From the outside that can look contradictory.

Here is what I have come to believe after shipping both: low-code and pro-code are not rivals. They are different delivery models. There is a narrow but important band of enterprise work where OutSystems is the correct answer, including for teams that could have written the application by hand.

This field note is about finding that line before the platform decision becomes expensive to reverse.

The Decision In One Sentence

Use OutSystems when the work is an enterprise operations application over existing systems, with known users, workflow complexity, integration weight, and a clear governance model. Use Next.js or another custom-code stack when the work is a customer-facing product, a brand-sensitive digital experience, a high-concurrency SaaS platform, or a deeply custom AI/product engineering system.

The practical distinction is not low-code versus real engineering. The practical distinction is operations workflow versus differentiated product surface.

What OutSystems is actually good at

Strip the marketing. The thing OutSystems does better than Next.js + Express + Postgres is workflow applications over existing enterprise data, with strong integration patterns, mobile support in the same platform, and faster time-to-first-version than any stack I've shipped.

Concretely, the wins I've seen:

• Integration-heavy business apps. Claims intake, dispatch orchestration, multi-step approval flows. The kind of app where 60% of the work is integrating with the old SOAP service, the ancient ERP, and the email gateway. OutSystems pays back on integration patterns.
• Mobile plus web in one stack. An app with a dispatcher desktop UI, a driver mobile app, and a floor supervisor tablet view, all with shared business logic. One OutSystems codebase, three UI surfaces, all deployed together. Doing this in React + React Native with a shared backend is faster to start but harder to keep coherent over three years.
• Enterprise buyer momentum. Some buyers require a named low-code platform. OutSystems being an option means work that would have gone to another vendor stays with us.

What Next.js (and a real backend) is still better at

The list is longer. This is where I'd resist the low-code pitch:

• Public-facing, SEO-critical, brand-sensitive apps. Marketing sites, e-commerce, anything where page-weight, rendering strategy, or UX fidelity matters. Next.js + a headless CMS + our design team will ship a better product than an OutSystems Reactive Web App. Not because OutSystems cannot do it, but because the defaults do not fight for you the way Next.js defaults do.
• High-concurrency product apps. Any app where the read-write ratio is skewed heavily to reads, serving thousands of concurrent users. OutSystems can scale, but the cost curve is steeper than a well-architected Postgres + cache + CDN stack.
• Heavy AI features. Custom RAG, agentic workflows, LLM evaluation pipelines, and similar work live more naturally in Python or TypeScript services with Claude or OpenAI clients. OutSystems has AI features; they are not where most of the ecosystem is building.
• Deep design work. If the UX requires custom animation, unusual layouts, or the design team wants to iterate fast in Figma-to-Storybook loops, OutSystems becomes a tax. Custom HTML/CSS in OutSystems is possible but fights the platform's model.
• Long-lived SaaS products. When the product is the business, the business case for owning the stack completely is strong. OutSystems licensing at scale becomes a line item that's hard to justify vs a small platform team.

The fork: ops vs product

A useful framing: is this app an operations app or a product app?

• Operations app: used by a defined internal or partner user base. Known users, known devices, predictable concurrency. Its purpose is to run the business. UI polish is secondary; reliability and integration are primary. Examples: dispatch, claims intake, internal approval flows, back-office tooling.
• Product app: used by customers, public, or a rapidly growing user base. Unknown users, unknown devices, variable concurrency. Its purpose is to be the product. UX, performance, and evolution velocity are primary.

OutSystems almost always wins for ops apps where integration dominates. Custom-code stacks almost always win for product apps. The gray zone is small: heavily internal product apps (high UX expectations but low concurrency) and operations apps with consumer surface area (high concurrency on the consumer side, back-office on the internal side).

The gray zone is where discipline matters

Most bad platform decisions happen in the gray zone.

OutSystems deserves a serious look when:

• The users are known, authenticated, and process-driven.
• The work is mostly workflow, forms, approvals, data lookup, and integration.
• The app needs web and mobile surfaces with shared business logic.
• The business wants change velocity but can accept platform conventions.
• A governed platform team will own architecture, releases, support, and enhancements.

Next.js or another custom-code stack should stay the default when:

• The application is part of the public customer experience.
• SEO, experimentation, analytics, performance, or design fidelity are material.
• The product roadmap depends on custom AI, model evaluation, data products, or unusual interaction patterns.
• The concurrency or cost curve matters enough to justify deeper stack ownership.
• A product engineering team will own the roadmap for years.

If the decision still feels close after this filter, do not decide through opinion. Run a spike.

What I've stopped arguing

Two things I used to push back on and have stopped:

"OutSystems is slow at runtime." It isn't, in the context where you'd use it. The runtime is fine for the workload. Perceived slowness is usually about SQL queries generated by the platform's ORM, not the runtime itself. Tune the queries, don't abandon the tool.

"OutSystems creates tech debt." It does, if you skip engineering discipline. So does every platform. OutSystems with CI/CD, code review, ATF tests, and architectural standards is fine. OutSystems treated as "anyone can build this" is a disaster. That's not a platform problem; it's a governance problem.

How I now advise clients

Three questions, in order:

1. Is this an operations app or a product app? If product, default to pro-code.
2. How much of the work is integration with legacy enterprise systems? If >40%, OutSystems gets a strong look.
3. Who will maintain it in three years? If the answer is an internal team that's more analyst than engineer, OutSystems with strict guardrails may be a better fit than a Next.js app that slowly decays.

For anything truly borderline, we ship a two-week paid spike in each stack and compare the artifacts. It costs a bit up front and saves a lot down the line.

What The Spike Should Prove

A useful spike is not a beauty contest between tools. It should answer the risks that will matter after go-live.

For an OutSystems spike, prove:

• The critical integration pattern works without fragile shortcuts.
• The data model and module boundaries are maintainable.
• The role and permission model is clean.
• The target workflow can be changed quickly without creating hidden debt.
• The release and support model is realistic for the client team.

For a Next.js/custom-code spike, prove:

• The UX and performance requirements justify stack ownership.
• The backend services, integrations, and data model are not being under-scoped.
• The team can support the codebase, pipeline, observability, and security model.
• The long-term cost and roadmap control justify the custom build.

The result should be a decision record, not just a prototype.

Decision Matrix

The matrix is not a rulebook. It is a way to make tradeoffs visible before the enterprise commits to a platform direction.

Hybrid is often the real answer

The right architecture is sometimes both.

An enterprise may use OutSystems for internal operations workflows while keeping customer-facing web, AI services, analytics, and integration services in custom code. That can work well when the boundaries are explicit:

• OutSystems owns the workflow UI and role-based operations experience.
• APIs or integration services own access to SAP, Salesforce, ServiceNow, databases, or custom platforms.
• AI, RAG, analytics, and high-scale services live outside OutSystems where the engineering ecosystem is stronger.
• Release ownership, monitoring, and support are defined across both stacks.

Hybrid fails when every layer reaches into every other layer. It works when responsibilities are clear.

Governance Required For OutSystems

OutSystems succeeds when it is treated as an engineering platform, not a shortcut around engineering.

Minimum governance:

• Architecture standards for modules, integrations, and shared services.
• Code review and naming conventions.
• Environment strategy and deployment gates.
• Automated tests for critical workflows.
• Reusable UI and integration patterns.
• Security review for roles, permissions, secrets, and external APIs.
• Performance review for data queries and high-volume screens.
• Ownership model for enhancements, defects, and platform upgrades.

Without this, the platform can produce fast first releases and slow second-year maintenance.

The key point: OutSystems still needs engineering leadership. The platform accelerates certain kinds of delivery; it does not remove the need for architecture judgment.

What I'd never do

• Build a customer-facing marketing site on OutSystems.
• Run heavy AI workloads inside OutSystems flows.
• Standardize a product engineering team on OutSystems as its primary stack.
• Skip engineering discipline because "it's low-code."

Practical Checklist

• Classify the application as operations app, product app, or hybrid.
• Estimate the percentage of effort driven by integration and workflow versus differentiated UX.
• Confirm long-term ownership and support team composition.
• Identify security, audit, mobile, offline, and performance requirements.
• Compare two-week spike results when the decision is borderline.
• Define governance before build starts.
• Keep heavy AI, analytics, and custom compute in appropriate services, even when the workflow UI is OutSystems.
• Write a decision record that captures why the platform was chosen, what belongs outside it, and who owns support after launch.

The short version: OutSystems is a tool. A good one, for the right work. Teams that reflexively dismiss it miss a genuine productivity win on operations apps. Teams that adopt it as a default end up regretting it when the first product app goes live.

Pick the tool for the work. Not the work for the tool.

Kabir Malhotra leads the Product Engineering practice at Prometheas. For a second opinion on a stack decision, drop a note.