Your first app handles purchase requests for one department. The next proposal is a supplier portal, and a third team wants its own workflow. Mendix pricing should be evaluated against that application plan and the place each app will run. A starting subscription figure does not establish the cost of deploying the whole portfolio.
Choose One App when there is one funded application with a defined owner. Evaluate Unlimited Apps when several applications have credible delivery plans and a shared operating budget. Keep your existing tool if it meets the workflow and access requirements; a possible future portfolio is not enough reason to rebuild a working process today.
What the public starting prices cover
The Mendix pricing page, checked October 26, 2026, shows Standard starting at $1,090 per month for One App and $2,725 for Unlimited Apps. Premium requires a quote. Mendix says the app-count options have the same technical capabilities, and Standard and Premium license prices exclude compute resources. Treat those numbers as starting points for an estimate.
For an illustrative comparison, hold the workload constant: one purchase-request application, 40 internal users, the same data volume, the same deployment region, and a full year of operation. The table annualizes the displayed USD starting rates. It does not establish the billing cadence, minimum commitment, or complete price for 40 users; those details need the written offer.
| Standard option | Published monthly starting rate | Twelve-month equivalent | Complete workload price |
|---|---|---|---|
| One App | $1,090 | $1,090 × 12 = $13,080 | Unknown until user and deployment terms are quoted |
| Unlimited Apps | $2,725 | $2,725 × 12 = $32,700 | Unknown until user and deployment terms are quoted |
Ask for both offers against that identical workload, with user rights, compute, environments, services, taxes, and any add-ons itemized. Then ask how the offer changes when the second application is approved. Do not multiply the One App starting figure and call the result a portfolio quote: user licensing and commercial terms can change with the scope.
If Power Apps is also on the shortlist, Power Apps pricing covers a different licensing structure. Give both vendors the same user population and workflow. A comparison between a Mendix deployment estimate and an isolated per-user headline would leave different costs out of each side.
Decide what belongs in the first application
Write down the first release boundary before discussing unlimited applications. For the purchase-request example, include the requester, the approving manager, the fields they need, and the output sent to the purchasing team. Identify the record that confirms approval and the source of the department code. A supplier portal with a separate audience and release schedule deserves its own estimate.
Avoid placing unrelated workflows in one app just to fit a license assumption. That design can leave separate departments waiting for the same release or give one app more access than its original purpose required. Ask Mendix to confirm the contractual application boundary against a diagram of the planned deployment, rather than using the number of screens as a proxy.
Mendix’s licensing documentation distinguishes single-app internal users, multi-app internal users, and external users. Employees and contractors fall within its internal-user definitions. Apply those definitions to the proposed supplier portal as well as the departmental app; someone working outside the office is not automatically an external user for licensing purposes.
Choose the deployment before requesting the final amount
Mendix’s Cloud documentation distinguishes Free Apps from licensed deployments. Its Free App table lists a single environment, sleep after inactivity, and no scheduled-event execution. Use that environment to investigate an allowed prototype, but evaluate a scheduled purchasing workflow on the deployment that will run it in production.
Specify where production and acceptance testing will run, who operates them, and how much data each holds. Include the handling of documents attached to requests and a recovery requirement that the business owner can explain. If the purchasing process cannot wait through an outage, make that a requirement in the quote instead of assuming every paid option meets it.
Mendix’s licensing instructions for other clouds also describe restrictions on unlicensed apps outside Mendix Cloud and a separate Operator license for Mendix on Kubernetes. Moving to infrastructure you already pay for does not by itself remove licensing work. Confirm the runtime and deployment charges for the selected arrangement.
Use the purchase request to test both estimates
Prepare fictional requests for two departments, including an amount, currency, requester, approver, supporting file, and status. Add a request whose approver has left the company and one whose department code is missing. The expected outcome is an approved request visible to the right purchasing team, while incomplete or unassigned work remains visible to its owner for resolution.
For each proposed deployment, build the same request model and approval behavior, configure identities, and run those cases with separate requester and approver accounts. Check that a requester cannot approve their own submission unless your policy permits it. These are proposed evaluation steps, not reported product tests. Record implementation effort as you go, including any additional component or service required.
Mendix’s security documentation separates development-team access from end-user access and describes controls for pages, data, and application logic. Include both in the trial. A person who can help build an app should not receive business approval authority by accident, and hiding a page alone should not be your evidence that its records are protected.
Keep a recovery and exit plan in the scope
Mendix documents downloading a full snapshot, database, or files from an eligible environment in its backup instructions. Confirm who has that permission and rehearse a recovery with permitted sample data. A database backup gives you a data asset to restore; it does not establish that another application product can execute the same workflow.
If replacing an existing tool, inventory the records, attachments, identifiers, access rules, and integrations that must move. Budget for rebuilding the approval behavior and reconnecting credentials, then compare a completed request in both environments. Set a cutover owner and retain an agreed rollback period. The ERP migration article covers the broader reconciliation work when the application depends on records from a changing source system.
Where Permute fits: definitions shared across applications
Permute is the connected business data and custom application software we sell. Our interest in this evaluation is commercial. When a request app, NetSuite, and a departmental spreadsheet use different department codes, we can help reconcile those records and preserve the source evidence. The business owner still needs to decide which mapping is correct.
We can apply declared definitions, such as which statuses count as committed spend, in repeatable outputs built on that connected data. A department lead can inspect the records, definitions, and freshness behind a report, subject to access permissions. This becomes useful when a second app needs the same business meaning and should not maintain a separate interpretation.
Inspect the data behind an app
Start with permitted records and review the definitions that affect their interpretation.
Keep the application and data work scoped
We do not sell Mendix licenses or promise a native Mendix integration. Source access, application permissions, and any business actions must be scoped before implementation. Enterprise app development covers that planning. An existing Mendix application can remain the right place for its workflow while shared definitions and connected data are evaluated as separate work.
Buy against an approved application plan
Start with the application that has an owner, a defined workflow, and a deployment requirement. Use published Mendix starting rates to frame the discussion, then request the full workload price on consistent terms. Expand the estimate when another app has a credible delivery plan. Keep user rights, operating costs, and migration work visible so the second app does not arrive with an unexplained budget increase.
Scope the shared data work
Bring the first application and its planned follow-up to discuss source access, definitions, and implementation boundaries.
Questions about budgeting a Mendix application
Is the displayed Standard price the whole annual budget?
No. The annualized starting amounts above exclude the deployment and user terms that still need confirmation for the example workload. Request an itemized offer and verify the contract period rather than treating twelve times the monthly display as an invoice.
Should a possible second app push us into Unlimited Apps?
First establish whether the second app has an owner, approved scope, and a delivery plan. Ask for the cost of expanding from the first application alongside the portfolio offer. An unfunded idea gives you little basis for estimating when the broader license will be used.
Do contractors count as external users?
Mendix includes contractors in its internal-user definitions. Confirm how every participant is classified in the written offer, especially when a portal serves both suppliers and people working for your organization. Physical location alone does not establish the license category.
Can a free prototype establish production readiness?
It can help evaluate the application model and user flow with permitted data. The documented Free App limits mean it does not demonstrate scheduled-event behavior or the operating setup of a licensed deployment. Repeat the acceptance cases in the proposed production arrangement before committing.