Jmix · engineers into your team
Jmix engineers are scarce in Italy. This page says how many, how fast, and on what contract.
One or two engineers who have shipped production systems on this platform, working inside your repository, your sprint and your standards, for a fixed period with an end date in it. Useful when you own the domain knowledge and are missing the hands.
Three things on this page are worth more than the usual claims about benches and vetting: what we will and will not call a Jmix developer, the legal shape of the arrangement in Italy, and what we insist on so that your organisation is not left depending on a person who is leaving.
The contract
Who directs what, and why your legal team will ask
In Italy, supplying workers who take their instructions from the client is somministrazione di lavoro, and only an agency entered on the Ministry's albo may do it. We are not an agency and do not present ourselves as one. What we sign is a contract for services under art. 1655 of the civil code.
The two are not told apart by what the contract is called. Art. 29 comma 1 of D.Lgs. 276/2003 distinguishes them by three substantive things: the contractor organises the means needed for the work, exercises organisational and managerial power over its own people, and assumes the business risk. If those sit with the client in practice, the paperwork does not save either party.
So the division below is not a formality we observe on paper and ignore in the stand-up. It is how the engagement actually runs.
The people
What we will and will not call a Jmix developer
The framework is Spring Boot and Vaadin underneath, which means any competent Java developer can be productive in it eventually. "Eventually" is doing a great deal of work in that sentence, and it is usually paid for by the client. So the bar we apply before we put somebody forward:
- At least one system in production. Shipped on Jmix or on CUBA Platform, which is the same lineage, and still running after the handover. Not a prototype and not a course.
- The access model, properly. Roles, entity and attribute permissions, row-level constraints — and what each costs when the data loads. This is where the platform is strongest and where inexperience is most expensive.
- Can read the SQL the framework generates. Any platform that writes queries for you will eventually write a bad one. Knowing where to look is the difference between a performance ticket and a rewrite.
- Spring without the platform. If somebody only knows how to do things the Studio way, they will reach for the framework when the answer is ordinary Spring, and the system will get stranger every quarter.
And one thing that works in the other direction: we tell you the person's weak spot before you meet them. Strong on the platform, new to your domain. Excellent engineer, quiet in a meeting of twelve. You will find out in week three anyway, and finding out in week three costs you three weeks.
The failure we design against
Month seven, when the contract ends
The way this model fails is not bad code. It is that six months in, one external person is the only one who understands how the access model is configured, why a particular screen was built the way it was, and which of the forty entities is the one everything else hangs off. The hiring problem you solved has quietly become a dependency problem, and the invoice for it arrives at the end.
Three things in the engagement exist only to prevent that:
- Pairing from week one, not from the last month. One of your people, named, with time actually allocated. If nobody can be named, the engagement is worth less than it costs and we will say so.
- Decisions in the repository. Short records of what was decided and what was rejected, next to the code, in your language if you prefer. Conversations in chat do not survive the person who had them.
- A handover date in the contract. Written when the contract is signed, not negotiated when it expires. Two sessions, the second one a week later, after your people have tried to do it themselves and have found the questions.
The practical part
Sizes, notice and endings
The numbers people ask for on a first call, in the order they usually ask for them.
01 · How many
One or two, exceptionally three. Past that it is a team rather than augmentation, and a team should be contracted as one — with a scope, a delivery obligation and somebody on our side accountable for it.
02 · How fast
Two weeks from a signed order in the ordinary case. Four if the profile is specific: a regulated domain, an unusual integration, a language requirement beyond English and Italian.
03 · How long
One month minimum, three to six typical. Below a month the ramp-up costs more than the engagement returns, and we will tell you that rather than invoice it.
04 · Where
Remote from Italy, in your working hours. On site for the kick-off, and whenever the domain needs a room and a whiteboard — which is more often than remote-first suppliers like to admit.
05 · Licences
Studio is licensed per developer seat and that includes ours. We invoice it in Italy, in euro, through the SDI like any other Italian supplier — and the licence remains yours after we leave.
06 · Ending it
Thirty days, both directions, symmetrical. A notice period that is short for the client and long for the supplier produces a supplier who protects the engagement instead of the system.
Adjacent questions
Three cases where this is the wrong instrument
Nobody is free to direct the work
Augmentation assumes a technical lead with time to give. Without one, an engineer inside your sprint produces competent work on the wrong things, and the first person to notice is the auditor.
The platform decision is not made
Then hands are premature. The question is whether this is the right platform at all, which takes two to five days and sometimes ends in no — what a review looks at and what it produces
You are leaving CUBA Platform
A migration is not steady-state development and should not be staffed as if it were. It is assessed first, then run in waves — what moves, what gets rewritten, what has no replacement
Questions
The ones that come up before a purchase order
How many engineers can you actually place?
One or two, exceptionally three, and the honest reason is that the pool of engineers who have shipped production systems on this platform is small everywhere and very small in Italy. A supplier who offers you eight next week is either counting Java developers who have read the documentation or counting people who are already committed elsewhere. Beyond three it stops being augmentation anyway: that is a team, and a team needs a different contract and a different conversation.
Is this staff leasing? Our HR department will ask.
No, and the distinction is statutory rather than cosmetic. Supplying workers who are directed by the client is somministrazione di lavoro, which in Italy only an agency entered on the Ministry's albo may provide. We are not such an agency. What we provide is a contract for services under art. 1655 of the civil code, which art. 29 comma 1 of D.Lgs. 276/2003 distinguishes by three things: the contractor organises the means, organises and coordinates its own people, and carries the business risk. In practice that means you set the backlog, the priorities and the acceptance criteria, while the engagement of each person — the contract, the fee, the equipment, the substitution — stays entirely with us and you never become their counterparty. Our people are engaged as independent professionals, in Italy with their own VAT registration and abroad under their own national registration. Your labour lawyer should confirm this against the contract rather than against a web page.
What is the notice period to start, and to stop?
Two weeks is typical to start, four if you need a specific profile — a particular integration, a regulated domain, a language. Stopping is thirty days in both directions. A notice period that is short for you and long for us tends to produce a supplier who protects the engagement rather than the system.
Can they work inside our repository and our process?
Yes, and they should. Your branch strategy, your review standard, your definition of done, your ticketing. We have opinions and will offer them once; after that it is your system and your rules. What we do not do is accept a process that prevents our people from writing down what they decided, because that is how you end up dependent on them.
What happens to the knowledge when the engagement ends?
It is a deliverable with a date, not a courtesy at the end. Pairing with one of your people from the first week, decisions recorded in the repository rather than in chat, and a handover session scheduled when the contract is signed rather than when it expires. If you have nobody to pair with, say so at the start — it changes what we recommend, and sometimes it changes the answer to whether you should do this at all.
Do we need our own Jmix licences for this?
Yes. Jmix Studio is licensed per developer seat, and that includes ours while we work on your project. We are the seller of record in Italy, so the licence can be invoiced here, in euro, with an Italian VAT number and electronic invoicing — but it is your licence and it stays yours when we leave. The framework itself is Apache 2.0 and costs nothing either way.
Next step
Tell us who the engineer would sit next to
Not the job description — the person on your side who will direct the work and the person who will still be there afterwards. Those two names decide whether this works.
Ask about availability
What we can place, when, and at what rate. If we cannot staff it we will say so in the first reply rather than the third.
ContextWhat Jmix is, without the brochure
The licensing model explained properly, the shape of project it suits, and the shapes it does not.