Skip to content

Flexiana · ten years, about fifty people, twenty countries

We build software around the decisions your company makes every week, and we cost it before we build it.

Most of what we build replaces something that already works: usually a pricing routine somebody wrote in 2019, or a weekly schedule that one planner carries in her head, or an overnight job that used to take twenty minutes and now takes four hours. A company lives with these because they function, and because nobody has ever worked out what a better version would be worth. Working that out is the first thing we do, and it takes two to three weeks.

Our rule of thumb: if a better method would return about ten euros for each euro it costs to adopt, your people's time counted along with our fee, we build it. If it would not, the audit ends there and you have paid a fixed fee for a clear answer.

You do not have to take our word for the engineering. Some of the code is public, and here it is.

Where our software runs

100M+ people

use a sports platform whose nine internal systems we wrote and still run for Livesport. Guaranteed Rate, Zimpler, Cloudpermit, Crossbeam and Stylitics have shipped on our engineering as well. We mention this first because it is the one claim on this page you can check by picking up the phone.

How we check our own work

We wrote a theorem prover to check our mathematics.

It is called Rainbow, and there is a 347-page book behind it. You will probably never open either, and you do not need to. What it means for you is that a number we give you has been argued with a machine before it is argued with you, and a machine is a less forgiving audience than a client.

Who you deal with

The person on the first call does the work.

Whoever takes your first call is the person who costs the work and then builds it. Everything we see is confidential, and we do not name a client anywhere without written permission. So most of what we have done in ten years is not on this site, and an owner who wants a reference gets one by phone.

What the company is made of

Three kinds of work, done by the same people.

We run a research lab, we make musical instruments, and we build decision systems for companies. That looks like three businesses, and in one way it is: a referee judges the first, a dancefloor at two in the morning judges the second, and a quarterly P&L judges the third. But the habit underneath is the same in all three. We state the problem precisely enough that being wrong would show, and then we test it on somebody's own data before anyone builds on top of it. The people move between the three, and the habit goes with them.

01 The Decision Lab

The research, with its limits written down.

Exact algorithms and machine-checked proofs, each with a statement of what it proves and what it does not. A result that survives a company's own data becomes a product. The ones that do not are published anyway, because a negative result saves whoever has the same idea next the month it cost us.

Enter the Lab

02 The Studio

The software we build for one company at a time.

When the expensive operation is particular to your business and no product fits it, we model it, work out what a better method is worth on your figures, and build the software that runs it every day. Most of the company's time, and most of its revenue, is this.

See what we solve

What we solve

The five questions we get asked most.

When a company comes to us it is usually with a symptom: thin margins, late projects, an overloaded team, or a plan that stops surviving the week. In our experience the symptom traces back to one of five operations, each run on somebody's judgement because no system handles it well. The first job is the same whichever it is: work out what the operation costs you now, on your own figures.

  1. Predict

    Which projects are likely to lose money?

    A forecast of cost-to-complete and the chance of a loss, per project, while a manager can still do something about it.

    Read
  2. Select · Schedule

    What should we accept, schedule or defer?

    Which orders to take and in what order to run them, when capacity, skills and deadlines all bind at once.

    Read
  3. Allocate

    Where should limited intervention be spent?

    Which defects, claims or cases a limited crew should handle first, by what each one costs if it waits.

    Read
  4. Coordinate

    Is engineering producing the expected result?

    Where engineering money goes and what the business got back for it, without turning any engineer into a score.

    Read
  5. Verify

    Can critical logic be trusted?

    A machine-checked proof of a rule that has to hold for every input, where tests can only sample.

    Read

Not sure which of these is yours?

Most people are not sure, and the first conversation exists to find out, at no cost.

How we work

How an engagement runs

An engagement runs in five stages, and the three below are the ones you buy one at a time, each with its own fee and its own question. You commit to the next only when the last one has earned it. The first stage can end with our advice to leave the operation alone. We arranged it this way after watching companies pay for builds the evidence never justified, and some of those companies were paying us at the time.

  1. 01

    Find

    Two to three weeks, fixed fee. We map the operation, the money attached to it, the constraints, and whatever data already exists, and we come back with a number and a recommendation. Sometimes the recommendation is to build nothing.

  2. 02

    Prove

    Four to eight weeks. We take the riskiest assumption from the audit and test it on your own data: a solver, a prototype, a proof, or a shadow run alongside the current method while nothing depends on it yet.

  3. 03

    Build

    The method that survived becomes software that holds up in production, with the integration, the monitoring, and an override a person can reach for. The same people who ran the first two stages run this one.

Work

Some of the work

Each case says what was at stake and what changed afterwards. None of them lists a technology stack, because the owner who paid for the work never asked about one.

All work
Livesport coordinate One of the world's most-visited sports-results platforms runs on a fleet of internal systems that must stay correct and fast under enormous, spiky load, where a coordination or data error is visible to tens of millions of people within seconds. Flexiana designed, built and operated nine internal systems for Livesport in Clojure, ClojureScript and PostgreSQL, data-oriented services built to be correct under load and maintainable by the client's own team. In production Nine internal systems delivered and running in production behind a platform with more than 100 million users. Clojure / ClojureScript · Data-oriented systems · PostgreSQL Flexiana (own product. Gitrevio) predict Leaders could see engineering activity, commits, tickets, deploys, but could not connect that work to project cost, risk and margin until the accounting period had already closed. We designed and operate Gitrevio: a multi-tenant platform that ingests 31 engineering, project and HRIS sources, resolves contributors to canonical identities, and runs a decision-science layer that forecasts cost-to-complete and flags margin and delivery risk while intervention is still possible. In production A working, security-hardened product with 31 connectors and a 165-function decision-science layer, running inside Flexiana and offered commercially, the product and its pricing are public at gitrev.io. Bayesian forecasting · Identity resolution · ELT / Prefect Flexiana Decision Lab (Rainbow) verify For a decision rule that must never violate a hard constraint — a capacity, a contractual limit, an exclusivity — tests sample the input space but cannot close it. The residual risk is exactly the case the tests did not draw. We built Rainbow, a Clojure-native dependent-type theorem prover with a 1,200-line trusted kernel, and used the operations-research algorithm catalogue as its proving curriculum — machine-checking algorithms rather than merely testing them. Formally proved All 222 catalogued OR algorithms carry machine-checked proofs — zero pending, zero refuted; the prover checks signed rationals, finite vectors, Bellman/value-iteration and gradient methods natively. Dependent types · Proof-carrying certificates · Content-addressed proof data

Products

Products

Something becomes a product here only once the method has held up in an engagement and somebody has paid for what it produces. That bar is why there are six of them and not twenty.

01 · Engineering value intelligence

Gitrevio

Shows where engineering money goes and what the business got back for it. It was built for founders and investors, and it does not turn any engineer into a score.

Explore Gitrevio

02 · Open-source theorem prover

Rainbow

A theorem prover in which proofs are ordinary data. The part you have to trust is about 1,200 lines. It machine-checks all 222 catalogued operations-research algorithms, and where a result is not proved the documentation says so beside it.

See Rainbow

We build in Clojure by choice and we contribute back: Rainbow, orhof and chachaml are open source, and the book behind them, Applied Higher Order Functions, is free to read.

Why Flexiana

Why we work this way

  1. The same people throughout

    The partner who frames the problem stays on it through the build and afterwards. We have been on the receiving end of the handover to a delivery team, and we do not do it.

  2. The small invoice comes first

    The first payment buys an answer to the riskiest question. Six months of scheduled work comes later, and only if the answer justifies it.

  3. The mathematics has to pay

    Operations research, machine learning and formal proof each get used where they earn their cost and nowhere else. A spreadsheet is the right answer more often than a mathematician would like.

  4. Built for your people to run

    The data path, the interface, the monitoring and the fallback are part of what we build. A method nobody in your company can operate is not finished, whatever the demo looked like.

The projects worth doing almost never arrive as a feature list. They arrive as something a company has been doing the same way for years because it works well enough, and nobody has asked what the better version would be worth. That is the question we are useful for.”
Jiri Knesl, Founder of Flexiana

Jiri Knesl — Founder, Flexiana

Author of Applied Higher Order Functions · behind Rainbow, orhof, chachaml, Gitrevio and LiveSet

FAQ

Questions we are asked

What does Flexiana do?

Somewhere in your company there is an operation that runs every day or every week: a price gets quoted, a route gets planned, a job runs overnight. Because it works, nobody has looked at it for years. We look at it, work out whether a better method exists, and put a number on what that method would be worth using your own figures. If the number is large enough we build the method and keep it running. If it is not, the audit says so and we stop, and you have spent two or three weeks finding that out instead of a year.

How are you different from a consultancy or a development agency?

A consultancy is paid for the report. An agency is paid for the build. Both of them are paid whether or not the work turns out to have been worth doing. We start with a short, fixed-fee piece of work whose only job is to find out whether the improvement is worth what it costs to adopt, counting your people's time as well as our invoice. Sometimes it is not, and the engagement ends there. When it is, the people who worked that out are the same people who write the software. There is no handover to a team you have not met.

What have you built and run?

Nine internal systems in production for Livesport, used by more than 100 million people; Gitrevio, an engineering-value-intelligence platform in production; Rainbow, a theorem prover past its v1.0 milestone; the open-source orhof library and the 347-page book behind it; chachaml; and the Flexiana Atelier music software.

Can we verify your claims?

Some of them, today. orhof, our operations-research library, is open source: 251 functions with zero dependencies, and you can read every one. So is chachaml. Rainbow, the theorem prover, is written and licensed, but its repository is not published yet, and the de-censoring work has been reproduced inside the company and not outside it. The pages that describe each of these say which is which. We also publish the research that did not work, because a reader who only ever sees our successes has no way to weigh them.

How big is the company, and how long have you been around?

About 50 people in roughly 20 countries, and ten years in business. Most of us are engineers, and most of the engineers have been here for years.

What does it cost to find out?

The first conversation costs nothing. After that there is an audit, at a fixed fee agreed before it starts, which takes two to three weeks and puts a number on the money involved. We priced it so that the answer "leave this alone" is still worth having paid for, because that is one of the answers it gives.

Where to start

Tell us about the operation you would rather not be running this way.

A partner will read it and reply with one of three things: it is worth an audit, an existing product already covers it, or you should not spend money on it. The third answer is free, and we give it more often than you would expect.