Services · custom software
We sell Jmix licences in Italy. Two of the four systems on this site are built on something else.
That sentence is here because it is the only useful thing a supplier can say about technology choice, and because you can check it in four clicks. A payment application in C# and .NET MAUI over a PHP and Laravel backend. A detection system in Python. A compliance platform on Jmix. A municipal system on the framework that became Jmix.
Discovery, architecture, build, launch and handover — on whichever of those stacks the system actually calls for. The page below is about how that call gets made, since everything else about end-to-end delivery is the same promise every supplier makes.
The four cases are the published part. Behind them are engagements we cannot name: a product whose four Flutter applications run against one Node.js and TypeScript backend, a platform with interactive 3D in the browser on React and Next.js over .NET 6, and a portal built from the first Figma frame to production on Django, Vue and PostgreSQL. The technologies are listed on the services page; the clients are not, and that is the agreement we make with everyone.
The actual method
What the system mostly is decides what it is written in
Not what is fashionable, not what we have engineers idle in, and not what carries a licence we happen to resell. The question is what the system is mostly made of — and then one rule that overrides the answer.
Declared interest
The bias we have, and what stops it deciding your architecture
Far Rainbow is the seller of record for Jmix licences in Italy. That is a real commercial interest in one of the four answers above, and a supplier who does not declare it is asking you to detect it instead.
Three things keep it honest, and you can verify all three:
- The published record. Two of the four systems on this site are not on that platform, and one of them is a payment application we still maintain.
- A review that can end in no. The architecture review before a build is written so that "not this platform" is a normal outcome, and the reasoning comes to you in a document you can take to another supplier.
- The licence is the small number. A platform decision commits you to years of engineering and hiring. Being wrong about it costs an order of magnitude more than anything we make on a subscription, which makes the long-dated self-interest and your interest the same thing.
Not always greenfield
Taking over code somebody else wrote
A good share of the work that arrives here is not a new system. It is an existing one whose authors have gone, whose framework has been abandoned by its vendor, or whose supplier relationship ended badly. That is a different engagement from a build and it starts differently.
- A fortnight of reading before any designing. The first deliverable is a written account of what the system actually does, which is reliably not what the documentation says and often not what the business thinks either.
- The riskiest deadline first. An unsupported framework, an expiring certificate, a store policy cut-off. These have dates attached and the dates do not negotiate.
- Nothing goes dark. Users keep using the system while it changes underneath them. On the payment application we maintain, the framework migration happened without taking the service down.
The case: replacing the foundation under a payment app while people were paying with it
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 reliable way to find out what the organisation actually does before the budget is committed to a guess about it.
03 · Something to look at, fortnightly
A working demonstration every two weeks, not a status report. A project where the first surprise arrives at the end is a project where nobody was looking, and that is a supplier failure rather than a client one.
04 · Your repository, from the first commit
Not at the final invoice, and not as an import of a finished codebase with the history flattened. The history is how the next engineer finds out why.
05 · Your infrastructure
Where your other systems already live, with your monitoring and backups. We can host during the build; going live on a supplier's infrastructure creates a dependency nobody chose and everybody later resents.
06 · A handover somebody else could use
Tested by a person who has never seen the project: clone, build, deploy, ship one change, each step without asking us. The five-step test, in full
Adjacent questions
Three cases where we are the wrong supplier
A package already does this
Then buy it. We will tell you which category to look in and what to check, and the conversation costs you a call rather than a project. Writing software that already exists is the most expensive way to be unremarkable.
You have the team, not the hands
If you own the domain knowledge and the technical direction, buying a whole delivery is buying what you already have — engineers inside your own process
The deciding factor is the day rate
There is always a cheaper team, and on a two-year system the day rate is not where the money goes — it goes into the rework caused by the discovery nobody did. If that argument does not land, the cheaper team is the right choice.
Questions
The ones that decide the contract
You sell Jmix licences. How do we know you will not propose Jmix for everything?
Partly by asking, which you should. Mostly by looking at what is already published here: of the four systems on this site, two are built on that platform and two are not — a payment application in C# and .NET MAUI with a PHP and Laravel backend, and a detection system in Python. The architecture review that precedes a build can end in "not this platform", and when it does, that is the recommendation you get in writing. We would rather be the supplier you call for the next system than the one who sold you a platform that did not fit this one.
Should we build this at all, or buy something?
Buy, if the process you are describing is one that thousands of companies run the same way — payroll, accounting, generic CRM, helpdesk. Package software is enormously cheaper than anything we could write, and the right move is usually to change the process to fit the package. Custom pays when the process is the business: when the thing you do differently is the reason customers choose you, and a package would force you to do it the way everybody else does.
Can you take over a system somebody else wrote?
Yes, and we have — including a payment application running on a framework Microsoft had stopped supporting a year earlier, which we took over, migrated and kept in production throughout. Taking over is a different engagement from building: it starts with a fortnight of reading rather than designing, and the first deliverable is usually a written account of what the system actually does, which is rarely what the documentation says.
How do you price it?
A fixed price per phase, for a phase whose scope is known. Discovery first, then the first release, then each wave priced on what the previous one taught. A fixed price for a whole system whose requirements are still being discovered is a bet, and whoever loses it pays either in margin or in a year of arguments about what "including" meant.
Who runs it in production?
Your infrastructure, by default and by preference, with your monitoring and your backup policy. We can host 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 nobody chose.
What does the handover actually consist of?
A repository with its history, a build that runs on a clean machine, database migrations from empty, a runbook, and decision records. We test it by having somebody who has never seen the project clone it, build it, deploy it and ship one change, each step without having to ask us. That test is written out in full on the Jmix page and it is the same test whatever the stack, which is why it is stated once rather than twice. It is the standard we work to, not a promise about a number of hours.
Next step
Start with the workflow, not the system
The one process that hurts most, and the person who owns it. That is enough for a discovery, and a discovery is enough to know whether the rest is worth doing — or whether you should buy something instead.