We sell Jmix licences in Italy. This page is about when not to buy one.

Fit

The shape of system this platform was built for

Jmix earns its keep on internal enterprise systems with a large domain model and a small, known audience. The economics are simple: the hundredth screen costs almost nothing after the first, because the framework generates most of it from the data model. If your system is mostly screens over a complicated domain, that is the whole argument.

• Many entities, many screens, few users. Back-office, operations, claims handling, logistics, treasury. The ratio that matters is domain complexity against audience size, and it should be high.
• Access control that somebody will audit. Permissions on entities, attributes and rows, enforced when data is loaded. If your security model is a real requirement rather than a checkbox, this is where the platform is strongest.
• A long life and a maintenance team. Standard Java and Spring underneath means the people who maintain it in 2032 are hireable. That is a procurement argument as much as a technical one.
• Replacing something nobody can maintain. Oracle Forms, Delphi, PowerBuilder, an ageing Java EE monolith. The database usually survives; the application around it does not.

The engagement

Two to five days, and a document you can take anywhere

A review is deliberately short. Past five days we stop learning things that change the recommendation and start producing pages that make it look expensive.

What it looks at:

• The domain. How many entities, how they relate, how much of the complexity is structural and how much is accident.
• The users and the access model. Who sees what, and whether that is a sentence or a hierarchy.
• The integration surface. What the system must talk to, in which direction, and who owns the other end.
• The interface expectation. Whether "it should look good" means usable and consistent, or means a design somebody will sign off on pixel by pixel. These have different costs by a factor.
• The team and the decade. Who maintains this after we leave, and whether that is realistic.

What you get — two documents, and the same discipline we apply to a technical audit:

• The finding, with its evidence base. A recommendation and the reasoning that produced it, not the reasoning's conclusion. Where a number is estimated rather than measured, it says so next to the number.
• A sizing you can argue with. Assumptions written beside each figure, so the argument is about an assumption rather than about a total nobody can take apart.
• A risk list ordered by what would actually hurt, including the information-security risks we noticed on the way past, whether or not you asked about them.
• A limitations section. What the study could not establish, and why — usually because the data was not there to establish it. A review with no limitations section has either not looked hard enough or is not telling you something.
• If the answer is yes: a skeleton architecture and a first-release scope. If it is no: what instead, and why.

And a boundary that is in our contracts, not just on this page

A review produces findings and instructions; it does not change your systems. Where the engagement is a technical audit, the second document is an implementation instruction written for your engineers — step by step, per component, with a verification procedure, a rollback procedure, test scenarios and an acceptance checklist — and your people or your other suppliers carry it out. We keep that line because an auditor who also implements has an interest in what the audit finds.