Engineering value intelligence
01Gitrevio
Connects engineering delivery to what the business got back, through 31 connectors and 388 agent-callable decision-science functions, in production for paying customers.
Explore GitrevioThe company
Ten years, about 50 people, and a habit of proving things first
Flexiana started ten years ago as a senior software-engineering team, and for most of that time we were paid to build what clients asked for. We are now something narrower and, we think, more useful: a company that works out what a better method for a repeated business decision would be worth, proves it on the client's own data, and then builds the software that runs it. The engineering is still here. The question of whether to do it comes first.
Ten years in business about 50 people around 20 countries
Why now, from the founder
What changed, and why we changed with it
For most of the ten years I have run this company, delivering capable, well-engineered software was itself the differentiator. A client who got a system that worked, on time, from senior people, was a client who came back. That is now table stakes, and I would rather say so than pretend the market has not moved.
The problems worth solving now sit one step earlier: in the repeated decisions a business cannot yet make well. Which work to accept. Where to spend limited effort. What can be trusted, and which project is quietly losing money. I watched clients pay us to build software around decisions that nobody had costed, and some of that software should not have been built. So the question I wanted us to answer first was whether a better method exists and what it is worth, before anyone writes a line.
Those problems reward operations research, decision-making under uncertainty, applied AI and formal methods as much as they reward engineering. So we built the team, the discipline and the products to work at that level. It took longer than I expected, the theorem prover in particular, and the company is smaller than it would have been had we kept selling capacity. But I would rather be asked what a decision is worth than how many engineers we can supply by Monday.
Jiri Knesl, founder
The three practices
Three kinds of work, one habit
We run a research lab, we make musical instruments, and we build decision systems for companies. Their audiences agree on almost nothing. What holds them together is a habit, and it is the same one in each: define the problem precisely enough that being wrong would show, then ship only what survived.
The Decision Lab
Judged by a referee
Questions written down before the data is opened, prior art stated, proofs checked by a machine, and negative results kept as results. If a claim would not survive a hostile reviewer, we do not make it.
The Studio
Judged by a P&L
Decision systems built for one company at a time and measured against that company's own baseline: margin protected, a loss avoided, a plan that survives the week. Each one was proved on that company's data before it was scaled, and we have not made an exception.
How we operate
Seven things you can hold us to
These describe how the work runs, including the points at which we decline it. They are written so that you can quote them back to us.
-
We start from the decision
The choice a business makes repeatedly and cannot yet make well is where we begin. A technology or a feature list is where other people begin, and so much software that nobody needed gets built that way.
-
We prove before we scale
The riskiest assumption is tested on your own data before anyone commits to a large build. It costs a few weeks and it has saved several years.
-
We label what we know
Every result carries its status: a hypothesis, a backtest, a proof, or a negative result. And every result says where it stops applying.
-
The senior people stay on the work
The person who frames a problem stays accountable through proof, build and operation. Nobody is handed anything by somebody who has left the project.
-
We build for the day after launch
Data, workflow, interfaces, controls, monitoring and a person who can overrule the system are designed in from the start, because a system that only works on demo day is not a system.
-
We publish what can be checked
The method and the evidence go out, including the negative results, so that a claim of ours can be checked by somebody who does not like us.
-
A product only after it has paid
When a method proves itself across engagements and somebody has paid for it more than once, it becomes a product, and not before that.
How we are organised
How we are organised
About 50 people in around 20 countries, most of them engineers who have been here for years. The person who takes your problem on the first call is the one who costs it and builds it, and that has been true for ten years.
Ten years of working across that many time zones leaves a mark. We write things down, because a conversation in Prague at nine is a document in Buenos Aires at four. We publish the evidence. We keep the interfaces between people clear, because unclear ones cost a day each way.
The result is work you can hold to account without being in the room for it. It is the only way we have found for senior people in 20 countries to build one thing together, and it turns out to be what a client wants as well.
Shipped
What we have shipped
The best way to judge a supplier is by what they have running somewhere. These are ours, and most of them are open enough to read before you decide anything.
Open-source theorem prover
02Rainbow
A dependent-type theorem prover in Clojure, past v1.0, whose 1,200-line trusted kernel machine-checks all 222 catalogued operations-research algorithms. It is open source, and its repository publishes with the release.
See RainbowOpen-source MLOps for Clojure
03chachaml
An MLOps platform for Clojure. MIT-licensed, shipped at v0.7.0, cljdoc-published, with a web UI, MCP support and chat-with-data.
See the productsWhere we belong
We build in Clojure, and we belong to its community
This is a preference, and after ten years of large systems we think we have earned it. Clojure is a small, stable functional Lisp on the JVM. It keeps a large system comprehensible, and it lets us change one safely years after it was written. Most of the cost of software is paid then. Nearly everything we ship, from a client's internal systems to our own products, is written in it.
A community you only draw from is not one you belong to. Our open-source work is written for other Clojure people to read, use and build on, and we intend to keep adding to the tools, the writing and the shared knowledge the community runs on.
Research commitment
We publish the working as well as the conclusion
Each item in the library states what was tested, what evidence exists, who reviewed it internally, and where the result does not apply. Negative results are kept. Independent external replay is named as the bar we are moving toward and have not reached. We do this because it is the standard we ask a client to hold their own decisions to, and it would be odd to ask for it and not meet it.
The fields we work in (operations research, decision-making under uncertainty, applied AI, formal methods, engineering intelligence) only earn their place when they change an outcome. Publishing is how we find out which ones did.
What we optimise for
What we optimise for
-
Longevity
We build systems meant to run and be maintained for years. Demoing well once is a different craft and a cheaper one.
-
Judgement
Experienced people applying discretion to specific problems. A process applied blindly is the sign that the experienced people have left.
-
Craft
Care in the parts nobody sees: the kernel, the controls, the evidence. Trust is earned in those parts, and it is lost there too, usually a year later.
-
Hospitality
Treating a client's problem as our own, including the moment when the right answer is not to build, the least hospitable thing to say and the most useful.
Start with the decision
Bring us a decision
Describe a repeated decision, an operational constraint or a product problem. A partner will reply with whether we are the right team for it, and if we are not, who might be.