About
A consultancy built for scientific systems
What we do
Specialised, not general-purpose
Generalist software consultancies can build applications but need the scientific context explained to them, and that translation is where requirements are lost. Instrument vendors build excellent software for their own hardware and have little reason to integrate deeply with anyone else's.
We work in the space between: custom middleware, orchestration, data engineering and scientific applications that make existing systems work as one workflow.
Every project we take on involves at least two of the following: laboratory hardware, an experiment-management system, an analytical data source, and a model that should be informing what happens next.
That constraint is deliberate. It keeps the work in an area where domain knowledge compounds — the same integration problems, failure modes and data-modelling decisions recur across organisations, and recognising them early is most of the value of specialisation.
We do not sell a platform, a licence or a seat count. Engagements are scoped as engineering work, and what we build belongs to you.
Expertise
Five disciplines, one team
Chemistry domain knowledge
We understand what a reaction array, an analytical method or a formulation screen actually is, so requirements do not have to be translated twice before work can start.
Laboratory automation
Practical familiarity with liquid handlers, schedulers, workcells and analytical instrumentation, including the failure modes that only appear in routine operation.
Software engineering
Typed, tested, documented systems designed for maintenance: versioned APIs, clear data contracts, deployment your team can own after handover.
Data science & ML
Bayesian optimization, design of experiments and predictive modelling implemented as production services rather than notebooks.
AI systems
Retrieval and agent architectures grounded in internal sources, with explicit tool surfaces, approval gates and complete audit logging.
How we work
Engineering commitments
Vendor independence
We build against your systems without tying you to a platform. Replacing one vendor should mean rewriting one adapter, not the whole integration.
You own the code
Source, documentation and deployment configuration live in your repositories. There is no runtime licence and no hidden dependency on us.
Built to be operated
Logging, health checks, retries and clear failure behaviour, because integration code fails in production in ways that demos never show.
Engineers, not account layers
You talk to the people writing the software. Requirements do not pass through an intermediary before reaching the implementation.
Technical stack
What we build with
Languages
- Python
- TypeScript
- SQL
- Rust (where it earns its place)
Backend & APIs
- FastAPI
- Node.js
- REST
- gRPC
- Message queues
Data
- PostgreSQL
- Time-series stores
- Object storage
- Airflow
- Prefect
- dbt
ML & optimization
- scikit-learn
- PyTorch
- BoTorch
- GPyTorch
- Optuna
- DoE libraries
AI systems
- Retrieval pipelines
- Vector databases
- Agent tool interfaces
- Evaluation harnesses
Laboratory interfaces
- Instrument control APIs
- Vendor SDKs
- Scheduler APIs
Infrastructure
- Docker
- Kubernetes
- On-premise deployment
- Cloud (AWS / Azure / GCP)
- CI/CD
Start with the systems, not the sales call.
Tell us which systems are involved and what should happen between them. The first response you get will be technical.