# Rebuilt on open building blocks

18 October 2025 · Essay · 5 min read

By [Ahsan Fazal](https://axiomatic.digital/en/about#ahsan), Founder and CEO

Six weeks in, we are rebuilding Inora from the ground up on open-source building blocks. A small company does not win by building everything itself, or by letting one platform make its choices. What we take, what stays ours, and what it costs.

Six weeks in, you do not tear up the foundation lightly. I know how it sounds. Even so, we are rebuilding the application from scratch. This is why, what we get for it, and what it costs.

## The moment

The decision started with one capability. I wanted to give Inora a writing surface: a document you write together with the language model, beside the conversation. In 2024 that was new; now everyone expects it. I worked out what it would cost us to build it ourselves: four to six weeks of custom development. For one capability.

Then I asked the question I should have asked earlier. Why build it ourselves? Why not take what already exists and make it ours?

It was not an isolated calculation. After the first version I meant to give Inora a new look in one short round. Halfway through, it became clear that building further on the shape we had, software built the traditional way, everything ourselves, layer on layer, was not the way forward. The writing surface was the moment I saw it.

## A small company does not build everything itself

Language models, and everything around them, change so fast that the rules shift fundamentally every few months. What led the field last year is this year’s floor, the least users expect. We are a new, small company. If every shift costs us weeks of custom work, we will always be months behind.

This is how I put it today: building everything ourselves is not how we win. We have to build on open building blocks the industry uses as its standard, which thousands of developers update every day.

That is the core of it. Open building blocks that the industry uses as its standard get better every day, through the work of people we could never have hired. Build on them and their work comes with it, day after day. After the rebuild, a new capability takes us a few days to a week, and a fundamental shift less than a month.

## No platform that decides for us

The second reason matters more to me. Until now, Inora has run on one platform for language models, and that platform made many decisions for us: which models we could use, and when.

Take speech. Suppose a speech model comes out tomorrow that is far better than the one we use now. Do we wait until that platform supports it? Or do we put it to use straight away? On the old foundation the answer was the first. On the new one it is the second.

I wrote down the principle behind it in one line, in English, the way I thought it: “We need to be in control; not to be subject to the incentives and direction of a third party.”

The principle is not new. On 13 June our plan put the foundation before any feature: Inora was to run in an environment we control, show the source with every answer and be tied to no single language model. Until now that held for the model. From this rebuild on, it holds for everything around it. No vendor sets our direction, and no one outside Axiomatic decides what we make.

## Dictation is already built

One thing is already in place: dictation. You press the microphone, you speak, and text appears, the way everyone knows it from the keyboard on their phone.

It was the example I used to explain the whole rebuild. Speech is becoming what users expect by default. In care that counts double, because hands are rarely free. Someone who wants to look something up or note something down between two clients has gloves on, a trolley in front of them, or an arm around someone. If they have to type first, they do it later, or not at all. On the old foundation we would have spent months catching up with that expectation. Now it is already there.

## What stays ours

Building on what thousands of people maintain does not make Inora less ours. It does the opposite. What anyone can download sets no one apart. And if you spend your time on what everyone already has, you have none left for what only you can make. So we take the building blocks, and we spend our time on three things no one else will build for us.

**The knowledge model.** On 4 July every organisation got a closed space of its own in Inora; every document kept its structure and its authority, and every question carried the role of the person asking it. On 16 August we began recording every intermediate step of every answer: which sources Inora used, and why. That is how a wrong answer could be traced to its cause. No building block delivers that ready-made. That is the work.

**The line.** Inora supports professionals with their organisation’s knowledge. It does not diagnose or decide on treatment; its intended use keeps it outside medical-device scope. Where that line sits is ours to decide, and no vendor’s setting moves it.

**The implementation.** Whether a system works shows only on the floor. What an implementation shows there belongs back in the product, and no one else will build that for us. It cannot be downloaded.

A building block is common ground. What we build on it is ours.

## What it costs

This is not free. The rebuild costs weeks of extra development before version 1.0 is in place. And to be honest, some of those weeks are down to me. It took several attempts to find the right building blocks, because I did not know everything I needed to know. I added today that this comes with new, unexplored ground. I still think so. On new ground you sometimes pick up the wrong block. Better now, six weeks in, than a year from now, when far more rests on it.

What it gives us: we can sprint in a market that moves absurdly fast, without waiting on someone else’s direction.

From today, every new capability gets the same two questions. Does it already exist, and do thousands of people maintain it? Then we take it. Does it touch the knowledge, the line or the implementation? Then we build it ourselves.

## Work in care and use Inora?

Sign-in and help go through your own organisation: your team’s project lead and ambassadors can help you.

## Read on

- [Variation is not noise](https://axiomatic.digital/en/updates/variation-is-not-noise.md): The case for replacing professional judgement with algorithms stands or falls with one assumption: that a brain is a computer. Where a judgement has no right answer apart from the judgement itself, difference between professionals is information. Give them the same sources, not the same conclusion.
- [A language model does not reason](https://axiomatic.digital/en/updates/a-language-model-does-not-reason.md): In 2025 I announced “reasoning” as a feature. The word was wrong. A language model picks the most likely next text, astonishingly well, and does not know what it does not know. So: the model writes, the sources decide what is true, code does what must be exact, the professional decides.
- [An evaluation set makes “any model” true](https://axiomatic.digital/en/updates/an-evaluation-set-makes-any-model-true.md): Since the rebuild I say Inora is tied to no single language model. The sentence is only true if we can show it. Without the organisation’s own questions and answers, swapping a model is a leap of faith; with them it is a test run. Why I count evaluation as a precondition, and where I part ways with the standard advice.
