Clarobix

Making complex things clear.

Systems for work where being wrong is expensive.

Getting to something that runs is no longer the hard part. Clarobix builds the systems where being wrong costs money, a licence or a patient — and stays accountable for them long after they are live.

Start a project See our work
  • Healthcare
  • Fintech
  • Commerce
  • Public Sector
  • Developer Tools

Selected work

Systems built by the people behind Clarobix.

Production systems shipped across healthcare, trading, public services and developer tooling. Some were delivered for other organisations. Some, like Orbit, are ours — built, owned and run, which is what keeps what we say about production honest.

Developer Tooling

Orbit

Published on npm, open source

npm

A launcher for AI coding agents — Claude Code, OpenAI Codex, Ollama and others. One command opens a menu, you pick, you are in. No config files, no environment variables, no repeated logins.

Every agent authenticates differently. The work was hiding that behind one menu without leaking the differences back to the user.

At stake: Provider credentials sitting on a developer machine. Handled carelessly, a leak is a bill that meters by the token.

  • Multiple accounts per agent — switch work, personal and client contexts instantly
  • API keys handled and stored automatically
  • Local models via Ollama, with no network dependency
  • First-run wizard completes setup in under a minute

Read the detail

  • Node.js
  • Linux
  • macOS
  • Windows

Healthcare

EHR Platform

Confidential

An electronic health records platform with AI voice documentation, serving multiple healthcare facilities from a single deployment.

Voice documentation is only useful if clinicians trust it. Accuracy, latency and HIPAA handling had to hold at the same time, across facilities sharing one deployment.

At stake: A wrong entry in a clinical record is a treatment decision taken on bad information. A boundary that leaks between facilities is a reportable breach.

  • Voice-to-text clinical documentation via Deepgram
  • Multi-facility management under one tenant model
  • 60% reduction in documentation time
  • HIPAA-compliant data handling throughout

Read the detail

  • Laravel
  • Vue.js
  • Flutter
  • Deepgram

Fintech

Derivative Trading Platform

A real-time derivatives trading system spanning several broker APIs, with automated execution and risk tooling.

Three broker APIs, one execution path. Reconciling their differences without adding latency to a live market feed was the whole problem.

At stake: A duplicated or mispriced order is real money, gone, in less time than it takes to notice it went.

  • Zerodha Kite, AliceBlue and Kotak Neo integrations behind one interface
  • WebSocket market data feeds at trading latency
  • Automated strategy execution
  • Position and risk assessment tooling

Read the detail

  • Python
  • FastAPI
  • WebSocket
  • PostgreSQL
All work

What we build

Three kinds of system.

Not a services list. These are grouped by what happens when they are wrong, because that is what decides how they have to be built.

Systems that move money
Payments, settlement, wallets, multi-currency reconciliation, marketplaces where several parties are owed different amounts. The difficulty is never the transaction. It is what the ledger says afterwards, and whether it agrees with everyone else.
Systems under regulation
Clinical records, public service delivery, anything holding personal data that an auditor will eventually ask about. Built so the controls, the audit trail and the evidence exist from the first release rather than being reconstructed under deadline.
Systems that cannot pause
Live market data, voice capture during a consultation, operations that carry on whether or not the software is having a good day. Latency budgets, failure modes and recovery paths are the design, not the hardening pass afterwards.

After the prototype

What still matters once it already works.

Producing something that runs is now the cheap part. This is the list that decides whether it survives contact with production, and none of it shows up in a demo.

Authorisation that actually holds
A role scoped to one facility quietly reads every facility. Nothing breaks, nothing logs, and nobody finds out until someone goes looking.
Money that reconciles
Payments that succeed while balances disagree. The gap is found by a customer or an accountant, weeks later, and by then it has moved.
An audit trail worth having
The system did the right thing and cannot demonstrate it. To an auditor that is indistinguishable from not having done it.
Failure modes and a way back
A third-party API returns something its documentation does not mention, at three in the morning, and the question becomes what the system does next.
Latency under real load
Correct output delivered after the moment it mattered. On a live feed that is the same as being wrong, and it only appears under load nobody simulated.
The data that already exists
The new system is sound. The ten years of records moved into it are not, and every downstream assumption inherits that.
Knowing before the customer does
A component has been failing for six days. Without instrumentation the first report comes from the person it failed.

How we use AI

AI writes a lot of this. A person answers for it.

AI writes a large share of the code here, and it should. On the ordinary parts it is faster and frequently better, and pretending otherwise would be theatre.

What it cannot do is be accountable. The data model, the authorisation boundary and the failure modes are owned by a person, and every line touching money or regulated data is read by one before it ships.

That promise is only honest because of how the company is built: deliberately small, deliberately senior. A forty-person shop cannot claim a human reads everything. We can, because there are few of us and each of us carries more.

Compliance

Someone has to answer for it.

An agent can write a working application. It cannot sign a business associate agreement, choose where data lives, defend an access log to a reviewer, or be the party that answers when a regulator asks who approved the data model. That part has not been automated and is not close to being.

What we build to, and what we hand over

Fit

Where we are useful, and where we are not.

Said plainly so neither side spends a fortnight finding out.

Good fit

  • Regulated domains, where an auditor eventually arrives
  • Systems that move, hold or owe money
  • Multi-role platforms where permissions are the hard part
  • AI running in production rather than in a demo
  • Integration-heavy operations across systems you do not control
  • Teams shipping quickly with AI and no senior review behind it

Not a fit

  • Brochure sites and marketing pages
  • Prototypes intended to be thrown away
  • AI demonstrations with no path into operations
  • Ordinary CRUD where being wrong costs nothing
  • Work where the lowest bid decides the outcome

How we think

Understand. Simplify. Build. Launch. Improve.

  1. 01

    Understand the problem

    Before anything is designed. Most failed software solves the wrong thing precisely.

  2. 02

    Simplify the complexity

    Complicated domains do not require complicated systems. Usually the opposite.

  3. 03

    Build the right thing

    Scoped to what matters now, structured so the next thing is not a rewrite.

  4. 04

    Launch it

    Shipped and in real use, where the remaining assumptions finally get tested.

  5. 05

    Improve it

    Against evidence from production rather than opinion from a meeting.

Capabilities

Depth where it counts.

Domain knowledge matters more than tool preference. These are the areas where we already know where the problems are buried.

Healthcare Technology

  • HIPAA-compliant platform architecture
  • Telemedicine and EHR systems
  • AI-assisted clinical documentation
  • Real-time patient monitoring

Fintech & Trading

  • Derivative trading platforms
  • Multi-broker API integration
  • Real-time market data pipelines
  • Payment and settlement systems

AI & Automation

  • Voice processing and transcription
  • Document understanding and automation
  • Real-time data analysis
  • LLM and machine learning integration

Commerce Platforms

  • Multi-vendor marketplaces
  • Inventory and fulfilment systems
  • Shipping and logistics integration
  • Multi-currency payment handling
Full capabilities

Ways to start

Four doors, not one.

A build is a large first commitment to make on a stranger. Two of these are fixed in scope and end in a written document you own either way.

Production readiness review Fixed scope, one to two weeks
A written assessment of a system that already exists: authorisation boundaries, data integrity, money paths, failure modes and what happens under load. Increasingly this is a codebase that was largely generated and has never been read end to end.
Compliance readiness assessment Fixed scope
A gap analysis against the regime that applies to you, delivered as an evidence pack rather than a verdict. You are told what exists, what is missing and what a reviewer will ask for first.
Build Project
The system itself, with the controls, audit trail and evidence built in from the first release. Retrofitting those into something already live costs several times what including them did.
Accountable architect Monthly
Ongoing ownership of the security boundary, the data model and the failure modes for a team that is now shipping faster than it can review. Evidence kept current, security questionnaires answered, audits survived.

Have something worth building?

Tell us what the problem actually is. If we are the right people to solve it, we will say so — and if we are not, we will say that too.

Start a project Email us