# OutSystems & Mendix > The two enterprise low-code platforms that show up in big-company job postings: what they actually are, what a real project looks like, and the lock-in and cost to weigh. --- # OutSystems & Mendix If you have ever scrolled enterprise job boards and seen "3+ years OutSystems" or "Mendix certified developer" as a hard requirement, you have met the strange middle world of enterprise low-code. These are not the drag-and-drop website builders your cousin used for a bake sale. They are platforms that large banks, insurers, manufacturers, and government agencies use to build internal business applications - claims portals, approval workflows, field-service tools - faster than a traditional code team could, while keeping IT in control of security and deployment. This guide is for the person trying to make a real decision: a founder weighing whether to bet a product on one of these, an ops leader who inherited an OutSystems estate, an analyst eyeing a career pivot, or anyone who keeps hearing the names and wants a straight answer about what they are and what they cost you long-term. You do not need to be a developer to follow along. You do need to be clear-eyed with yourself about the tradeoff at the center of both: you trade raw flexibility and portability for speed and governance. The three phases walk the arc. Phase one explains what "enterprise low-code" actually means - model-driven development, visual logic, and the two reasons big companies pay for it. Phase two walks through a real project end to end: the data model, the screens, the logic, the integrations, the deployment pipeline, and the team around it. Phase three is the part the sales deck skips - licensing math, vendor lock-in, the skills market, the escape hatches when the platform fights you, and the clear-eyed call on when to choose it and when to walk away. --- # What Enterprise Low-Code Is Picture a developer building an internal expense-approval app the traditional way. They write the database schema by hand, the backend API, the front-end screens, the validation, the login system, the audit logging, and then they wire it all together and spend a week on the parts that have nothing to do with expenses - connection pooling, session management, deployment scripts. Most of that work is plumbing every business app needs and nobody's users ever see. Enterprise low-code platforms exist to delete that plumbing. OutSystems and Mendix are the two best-known. Instead of typing the plumbing into existence, you describe your app in a visual model, and the platform generates the running application - database tables, screens, server logic, and the connective tissue - for you. ## Model-driven development, in plain terms "Model-driven" means the thing you build is a diagram of intent, not lines of text. You draw an entity called `Invoice` with fields like `amount` and `due_date`, and the platform creates the database table behind it. You drag a screen onto a canvas, drop your invoice data onto it, and you have a working list with paging and sorting. You draw your business logic as a flowchart - "if amount is over $5,000, route to the VP for approval, otherwise auto-approve" - with boxes and arrows instead of nested if-statements. The platform keeps these models in sync. Add a field to your `Invoice` entity and the database migration, the form input, and the data layer all update together. That tight coupling is the whole point: one change, propagated everywhere, with the platform handling the wiring you would normally get wrong by hand. ```text Traditional build Low-code build ----------------- -------------- write DB schema --> draw an entity write API endpoints --> (generated for you) build login + sessions --> built in, toggle on code each screen --> drag data onto a canvas write if/else logic --> draw a logic flowchart write deploy scripts --> one-click publish ``` This is not magic and it is not no-code in the strictest sense. The "low" in low-code means you still drop into actual code for the hard 10% - a tricky calculation, a custom widget, a weird integration. But the routine 90% is visual. ## Who buys this, and the two reasons why The buyers are large organizations with a backlog of internal apps and not enough developers to clear it. Banks, insurers, logistics firms, hospital networks, government agencies. They are not building the next consumer app; they are building the hundred unglamorous tools that run a business - onboarding portals, inspection checklists, claims trackers, dealer dashboards. They pay for two things: **Speed.** A small team can ship a working business app in weeks instead of quarters because the plumbing is gone. When the backlog is two hundred apps deep, that multiplier is the entire pitch. **Governance at scale.** This is the part that separates enterprise low-code from a weekend app builder, and it is often the real reason a CIO signs the check. The platform enforces who can deploy to production, keeps an audit trail of every change, manages environments (development, test, production) as first-class objects, handles single sign-on against the corporate directory, and bakes in security scanning. A regulated company cannot let a hundred shadow apps sprawl across random spreadsheets and Access databases. Low-code gives them a sanctioned, governed place for all of it - fast development that IT still controls. That combination - speed plus control - is why these tools command enterprise prices and show up as hard requirements in job postings. ## OutSystems vs Mendix at a glance They solve the same problem and look similar from across the room, but their personalities differ. | | OutSystems | Mendix | |---|---|---| | Origin | Portugal, founded 2001 | Netherlands, founded 2005 (now owned by Siemens) | | Build environment | Desktop tool (Service Studio) | Desktop + browser (Studio Pro and Studio) | | Reputation | Polished, opinionated, strong UI tooling | Model-first, strong for collaborative business+IT teams | | Collaboration angle | Developer-centric | Pushes "business analysts and developers in the same model" | | Cloud | Mostly vendor-managed cloud | Cloud, plus more on-prem flexibility | | Ownership | Independent (private) | Part of Siemens' industrial software stack | Two practical differences worth knowing. Mendix leans harder into letting non-developers (business analysts) work in a simplified studio alongside professional developers in the deeper tool - useful if your bet is on business-IT collaboration. OutSystems is more of a developer's tool with a reputation for refined front-end tooling and a more guided, opinionated experience. Mendix being owned by Siemens means its roadmap is increasingly tied to industrial and IoT use cases; OutSystems steers its own ship. For most decisions, the choice between them matters far less than the choice of whether to adopt enterprise low-code at all. That second question - what you give up, and what it costs - is what the next two phases are really about. First, what building on one of these actually feels like. --- # What a Real Project Looks Like Let's build something concrete: a field-inspection app for a facilities company. Inspectors visit buildings, fill out a checklist on a tablet, attach photos, and flag issues. Managers see a dashboard of open issues and assign repairs. It is exactly the kind of internal tool these platforms exist for - not flashy, but real, and a nightmare of plumbing to build from scratch. Here is what the build looks like, layer by layer, and who does each part. ## The data model You start with the data, because everything hangs off it. In the modeler you draw entities and the relationships between them. ```text Building (1) ----< (many) Inspection ----< (many) IssueFlag Inspector (1) ----< (many) Inspection ``` You define `Inspection` with fields like `date`, `status`, `inspector`, and a link to a `Building`. You add an `IssueFlag` entity with `severity`, `description`, and a photo attachment. As you draw, the platform provisions the underlying database tables and the data-access layer. There is no SQL to write for the common cases - you query and filter through visual data sources. When you later add an `assigned_to` field, the platform handles the schema change and updates everything that reads the entity. This is the layer where getting it right matters most. A clean data model makes the rest of the app fall into place; a messy one means you fight the platform for the whole project. The modeling skill transfers directly from traditional database design - entities are tables, relationships are foreign keys. ## The screens Next, the UI. You drag pre-built screen templates onto a canvas - a list screen, a detail/edit screen, a dashboard. You bind them to your entities, so the "inspection list" screen automatically shows your inspection data with sorting, paging, and search. You arrange widgets (input fields, dropdowns, date pickers, image uploaders) and the platform makes them responsive across phone, tablet, and desktop without you writing CSS for every breakpoint. Both platforms ship a component library and a theming system so your app inherits a consistent look. For the inspector's tablet flow you would use the mobile-optimized screens; for the manager's dashboard, the desktop layout. When the stock widgets are not enough - a custom map view of flagged buildings, say - this is where you drop into hand-written front-end code or pull in a custom component. ## The logic Business logic is drawn as flowcharts, called "action flows" in OutSystems and "microflows/nanoflows" in Mendix. For our app: ```text [Inspector submits inspection] | any IssueFlag with severity = "High"? / \ yes no | | create repair task mark Inspection notify manager as "Closed" set status "Urgent" ``` You build that by dropping action boxes onto a flow and connecting them. Decisions are diamonds, data operations are boxes, and you can call one flow from another to reuse logic. For genuinely complex computation you write a code expression or a custom action, but the orchestration stays visual so the next person can read the intent without reverse-engineering nested code. ## The integrations No business app lives alone. Our inspection app needs to pull the building list from the company's facilities system and push repair tasks into the existing maintenance ticketing tool. Both platforms consume REST and SOAP APIs by pointing at the endpoint or definition file and generating typed actions you can drag into a flow. There are pre-built connectors for common systems (SAP, Salesforce, databases, the corporate directory for login) in their marketplaces. Authentication against the corporate single sign-on is configuration, not code. Integrations are usually where a low-code project earns its surprises. The visual side is smooth until an upstream API is flaky, paginated oddly, or returns data in a shape the platform's generated structure dislikes - then you are debugging the seam between two systems, which is hard everywhere. ## The deployment pipeline This is the governance layer in action and a real strength. Your app lives in environments - typically Development, Test/QA, and Production - that the platform manages as first-class objects. You publish to Development with one click. When it is ready, you promote the exact same versioned package up the chain: Dev to Test, Test to Production. The platform tracks versions, shows you what changed, runs dependency checks, and can roll back to a previous version. Who is allowed to promote to Production is a permission, with an audit trail of every deploy. ```text Develop --> Test/QA --> Production (devs) (testers) (release manager approves) one-click promote of a versioned package, with rollback ``` Compared to wiring up your own CI/CD, this comes nearly for free, and it is a large part of what enterprises are paying for. ## The team around it A real project is not one person. Typical roles: - **Low-code developers** - build the entities, screens, and flows. The core builders. - **Solution/technical architect** - owns the data model, sets standards, decides what gets reused, keeps the app from rotting. - **Business analyst / product owner** - defines requirements; on Mendix especially, may build small flows directly. - **Release manager / platform admin** - controls environments, permissions, and promotions to production. - **Traditional developers** - write the custom code, components, and tricky integrations the visual tools can't reach. The team is smaller than an equivalent hand-coded project, which is the speed dividend. But "fewer people" is not "no expertise" - a badly architected low-code app rots exactly like a badly architected coded one. The platform speeds up the typing, not the thinking. Which brings us to the part you weigh before committing: what it costs, what you can't take with you, and when it's the wrong tool. --- # Lock-In, Cost & When It Fits The previous phases were the brochure: fast, governed, real. This phase is the conversation you have after the demo, when the contract is in front of you. Both platforms are genuinely good at what they do. They are also expensive, sticky, and wrong for plenty of projects. Here is the straight version. ## How the licensing actually works Neither vendor publishes straightforward per-seat pricing the way a SaaS app does, and both have reshaped their pricing more than once - so treat any specific number you read as a starting point for a sales conversation, not a quote. The shape is what matters. Pricing is built around a few levers, usually combined: - **Application size / consumption.** How big and complex your apps are - often measured in something like "application objects" (entities, screens, logic units). More app, more cost. - **End users.** Internal users versus external (customer-facing) users are usually priced very differently, with external users costing more. - **Environments and capacity.** Each environment (dev, test, prod) and the compute behind it factors in. - **Tier.** Both sell ascending tiers - a smaller starting plan up to large enterprise agreements with negotiated pricing. The blunt summary: a serious production deployment is a five-to-six-figure annual commitment, and the bill grows with usage. There are free or low-cost tiers for learning and small apps (Mendix has long offered a free tier; OutSystems offers a free developer edition), which are great for evaluation but not where the real money or the real apps live. Budget for the platform fee as an ongoing operating cost, not a one-time license - and model how it scales if your user count or app count grows, because that is where teams get surprised. ## The lock-in, stated plainly This is the single most important thing to understand before you commit. Your application is not portable. You are not writing code in a language you could move elsewhere; you are building inside a proprietary model that only that vendor's runtime can execute. ```text What you can take with you: What you cannot: - your data (it's in a DB) - the screens - the requirements/knowledge - the logic flows - custom code you wrote - the data model definitions - the whole app, as a running thing ``` If you decide to leave OutSystems or Mendix, there is no export-to-portable-code button. Migrating off means rebuilding the application on the new platform - re-implementing the screens, the flows, the integrations - from scratch. Your data comes with you because it lives in a real database, and the institutional knowledge of what the app does comes with you. The app itself does not. This is not a flaw they hid; it is structural to the model-driven approach. The same tight coupling that gives you the speed is the thing that locks you in. Go in with eyes open: you are renting velocity, and the rent includes a switching cost that compounds with every app you build on the platform. ## The skills market The flip side of lock-in is that the skills are scarce and therefore valued. "OutSystems developer" and "Mendix developer" are real, paid career tracks with vendor certifications that employers ask for by name. The talent pool is smaller than for mainstream languages, which cuts two ways: if you are hiring, expect a thinner market and to pay a premium or train people up; if you are building a career, certification in one of these can be a durable, well-paid niche precisely because the supply is limited and the customers are large enterprises with budget. Worth noting: the skills are somewhat platform-specific. A strong Mendix developer is not automatically an OutSystems developer. The transferable parts are the fundamentals - data modeling, logic design, integration thinking - not the tool muscle memory. ## Performance and the escape hatches For the apps these platforms are aimed at - internal business tools, forms-over-data, workflows for hundreds or thousands of users - performance is fine. The generated apps are real running applications, not interpreted toys. When you hit the platform's ceiling, both give you escape hatches. You can write custom code (extensions, custom actions, hand-coded front-end components), call out to external services, and drop to lower-level logic for the parts the visual tools can't express. That means you rarely hit a true dead end on functionality. But the escape hatches have a cost of their own: every line of custom code is a place the low-code promise breaks down - it needs a traditional developer, it is harder to maintain, and it erodes the "anyone on the team can read this" benefit. A project that is 90% visual and 10% code is healthy. A project that is 50% custom code is a sign you picked the wrong tool, paying enterprise platform fees to mostly write code by hand. ## When it fits, and when it doesn't **It fits when:** - You are an organization with a backlog of internal business apps and not enough developers. - Governance, audit, and IT control are genuine requirements (regulated industries especially). - The apps are forms, workflows, dashboards, and integrations over existing systems - the platform's sweet spot. - You can absorb an ongoing platform fee and accept the lock-in as a deliberate trade for speed. **It does not fit when:** - You are a startup building your core product. The lock-in, the cost, and the ceiling on differentiation make it a poor bet for the thing your company lives or dies on. - Your app needs deep custom logic, unusual performance characteristics, or pixel-perfect bespoke UX - you will fight the platform and pay for the privilege. - Budget is tight and the app count is low. The per-app economics only make sense at volume or at enterprise scale. - You need full portability and want to avoid betting on a single vendor's roadmap. The clean mental test: **enterprise low-code is for the apps that run your business, not the app that is your business.** If you are clearing an internal backlog under IT's watch, OutSystems and Mendix are strong, sensible choices and the lock-in is a fair trade. If you are building the product customers pay you for, the same lock-in that buys speed becomes a cage. Know which one you are doing before you sign.