Jmix · custom development
Built end to end, and handed over so that somebody else could maintain it.
Analysis, build, deployment, documentation, and a handover to whoever keeps the system afterwards — your team, your internal IT, or another supplier entirely. The last of those is the one worth designing for, because it is the one that tests everything else.
Every supplier offers end-to-end delivery, so the offer carries no information. What carries information is the exit: what you own at the end, in what form, and whether a stranger can clone the repository and get the system running without calling us. That is what this page is about.
Ownership
What you actually own, in three layers
People ask about lock-in as one question. It is three, and they have different answers:
- The framework. Apache 2.0. Free, yours, and not ours to withhold. No runtime fee and no per-user fee — the number of people using the system does not change what you pay.
- Your application. Ordinary Java or Kotlin on Spring Boot, in your repository, readable by any Java team. This is the part that matters in 2032, and it is the part that is unambiguously yours.
- Jmix Studio. A subscription per developer seat, used at development time. It is not required to run the application. If the subscription lapses, what you lose is development comfort, not a running system.
And the part the brochure does not lead with
Some capabilities live in paid tiers rather than in the free framework. The Enterprise tier covers things like maps and geodata, document management, collaboration features, omnichannel notifications and the multi-tab workspace; the BPM tier covers BPMN design tooling and the process engine. Reports and charts are free. Developing against the paid ones needs a matching active subscription.
Which means a design decision taken casually in week two can commit you to a subscription tier for the life of the system. We are the firm selling those subscriptions, and we would still rather tell you at the whiteboard: here is what this choice costs you annually, and here is the free path if there is one. Sometimes the paid add-on is obviously worth it. Sometimes it is a fortnight of ordinary code.
The deliverable
Five things a stranger must be able to do
This is the acceptance test for a handover, and it is run by somebody who has never opened the project — one of your people, or a supplier you are evaluating. We aim to run it at the end of every phase rather than once at the end, because a handover rehearsed four times is a handover and a handover attempted once is a hope.
The package
What arrives with the system
Not a binder. Five artefacts, each of which exists because its absence is a specific way the next team gets stuck:
- The repository with its history. Commits and branches intact, not a single import of a finished codebase. The history is how the next engineer finds out why.
- A build that runs from clean. One command, on a machine that has never seen the project, with the prerequisites listed by version.
- Database migrations, from empty. Every schema change as a script, applied in order, so a new environment is a command rather than an archaeology exercise.
- The runbook. Deploy, roll back, rotate a secret, restore a backup, read the logs — written as instructions somebody can follow at two in the morning.
- Decision records. Short notes on what was chosen and what was rejected, in the repository. The rejected options are the valuable half.
All of it written while the work happens. Documentation assembled in the final fortnight documents what somebody remembers, which is not the same thing as what the system does.
Money
Fixed price for what we can see
A fixed price for a phase whose scope is known is a commitment. A fixed price for a system whose requirements are still being discovered is a bet, and somebody loses it — either the supplier in margin, or the client in a year of arguments about what the word "including" meant.
So the work is fixed in pieces:
- Discovery. Two to five days, fixed fee, and it produces the scope of the first release. If it produces "do not build this", it has done its job.
- First release. Deliberately small: one real workflow, real users, in production. Priced before it starts.
- Waves after that. Each scoped and priced on what the previous one taught, which is the only honest basis for the number.
Where the estimate actually goes wrong
Not in the screens. In four places, every time: integrations with a system whose owner nobody can name; an access model discovered in month three rather than week two; "it should look good" turning out to mean sign-off pixel by pixel; and the migration of data out of whatever you are replacing, which is reliably the most underestimated line in enterprise software.
The engagement
How a build actually runs
01 · Discovery first
Two to five days with the people who know the domain and the people who will maintain the result. It produces a first-release scope, a risk list and a recommendation — including the recommendation not to proceed.
02 · A small first release
One workflow, end to end, used by real people in production. Small is the point: it is the only way to find out what the organisation actually does before the budget is committed to a guess about it.
03 · Waves, not a big bang
Each wave scoped on what the last one taught. The old system, if there is one, keeps running alongside until the new one has earned the traffic rather than been given it on a date.
04 · Your infrastructure
A Jmix application is a Spring Boot application and belongs where your other systems live, with your monitoring and backups. We can host during the build; going live on a supplier's infrastructure creates a dependency nobody chose.
05 · Handover rehearsed
The five-step test above, run at the end of every phase by one of your people. Problems found in phase one are a morning's work. Found at the end, they are a negotiation.
06 · Support, optional
A defined scope and a defined response time if you want it. The measure of the work is that you could choose somebody else — or nobody — without the system suffering for it.
Adjacent questions
Three cases where this is the wrong instrument
You have the team, not the hands
If you already own the domain knowledge and the technical direction, buying a whole delivery is buying something you have. What you need is capacity — how many, how fast, and who directs what
The platform is not chosen yet
Then a build proposal is premature and any number in it is decoration. The first question takes two to five days and sometimes ends in no — what a review looks at and what it produces
You already run CUBA Platform
Then this is not a new system, whatever the budget line says. Most of it moves untouched and the cost sits in a small, identifiable part — what moves, what gets rewritten, what has no replacement
Questions
The ones that decide the contract
Who owns the code at the end?
You do, from the first commit rather than from the final invoice. The work happens in your repository under your organisation where that is possible, and in ours only until yours exists. The Jmix framework itself is Apache 2.0, so nothing in the foundation is ours to withhold. There is no escrow arrangement here because there is nothing to escrow.
What happens if we fall out with you halfway through?
You take the repository, the runbook and the decision records, and you continue — which is why the handover test on this page is run at the end of every phase rather than once at the end of the project. A supplier who can only be replaced at the cost of a rewrite has an incentive we would rather not have. The commercial side is a notice period and an invoice for work done; the technical side should be a non-event.
Do you work fixed price?
For a phase we can see, yes, and we will put a number on it before it starts. For a whole system whose requirements are still being discovered, a fixed price is a bet, and the party who loses it pays either in margin or in a year of arguments about what was in scope. So we fix the discovery, then fix the first release, then fix each wave. If someone quotes a year-long system to the euro before discovery, ask what they have assumed — the answer is usually "the optimistic version of everything".
Does this lock us into Jmix?
Into the framework, to the extent that any framework holds the code it shapes — the same way Spring or Django or Rails does. Not into us, and not into a runtime fee: the licence is per developer seat and applies while people are developing, not while users are using. The real question to ask is narrower, and it is about premium add-ons rather than the framework. See the section above: some capabilities sit in paid tiers, and we tell you which ones a design would commit you to while the design can still change.
Who runs it in production?
Your infrastructure, by default and by preference — a Jmix application is an ordinary Spring Boot application and belongs wherever your other systems already live, with your monitoring and your backup policy. We can run it during the build if you have nowhere to put it yet, but a system that goes live on the supplier's infrastructure tends to stay there, and that is a dependency you did not ask for.
Do you maintain it afterwards?
If you want us to, with a defined scope and a defined response time rather than an open-ended retainer. But the page is built around the opposite outcome: the measure of a good handover is that the support contract is optional. We have done it that way and said so publicly — Smart Comune has been running since 2020 and our part ended at the handover.
Next step
Start with the workflow, not the system
Tell us the one process that hurts most and who owns it. That is enough for a discovery, and a discovery is enough to know whether the rest is worth doing.
Discovery, then a number
A first-release scope, a risk list and a fixed price for the phase — or a recommendation not to build it, which costs the same.
ContextWhat Jmix is, without the brochure
The licensing model explained properly, the shape of project it suits, and the shapes it does not.